Weirdness with AC86U, 384.11_*, and ExpressVPN

[Seth Harman]

I've noticed some odd behavior on my router since upgrading to the 384.11 and _2 versions of the firmware on my AC86U in regards to my VPN. I have five different OpenVPN clients setup on the router so I can bounce between different ExpressVPN servers when need be (sometimes servers experience speed issues so I switch). The clients are all configured to block VPN-bound clients from the Internet if the VPN goes down, and for each client I have the same list of devices that are bound to the VPN. On the last couple of versions of the firmware if I switch clients the VPN-bound devices on my network either can't access the Internet at all or cannot resolve certain domains until I switch back to whatever the original client was. This condition survives a reboot/power-cycle of the router. I've tried every combination of rebooting clients/router/devices/cable modem/etc... and nothing seems to fix the issue. I finally solved the problem today by removing 4 of the client configurations from the router so that now I only have one client configured. I've tested different ExpressVPN servers and, consistently, as long as I only have a single VPN client configured in the router I have no issues anymore. The behavior I'm seeing makes it appear as if the setting on the VPN client to "Block routed clients if tunnel goes down" is continuing to operate even if a new VPN client is brought online to replace the one that was in operation before. This is new behavior, I know from experience on older versions of the firmware that this did not occur and as soon as you brought up a new VPN the bound-devices weren't blocked in any way anymore. I'm also not really sure why this condition survives reboots/power-cycling the router even when I change which VPN client is the one that comes up by default upon boot. Anyone have any idea what's going on there?

 

[Martineau]

I've noticed some odd behavior on my router since upgrading to the 384.11 and _2 versions of the firmware on my AC86U in regards to my VPN. I have five different OpenVPN clients setup on the router so I can bounce between different ExpressVPN servers when need be (sometimes servers experience speed issues so I switch). The clients are all configured to block VPN-bound clients from the Internet if the VPN goes down, and for each client I have the same list of devices that are bound to the VPN. On the last couple of versions of the firmware if I switch clients the VPN-bound devices on my network either can't access the Internet at all or cannot resolve certain domains until I switch back to whatever the original client was. This condition survives a reboot/power-cycle of the router. I've tried every combination of rebooting clients/router/devices/cable modem/etc... and nothing seems to fix the issue. I finally solved the problem today by removing 4 of the client configurations from the router so that now I only have one client configured. I've tested different ExpressVPN servers and, consistently, as long as I only have a single VPN client configured in the router I have no issues anymore. The behavior I'm seeing makes it appear as if the setting on the VPN client to "Block routed clients if tunnel goes down" is continuing to operate even if a new VPN client is brought online to replace the one that was in operation before. This is new behavior, I know from experience on older versions of the firmware that this did not occur and as soon as you brought up a new VPN the bound-devices weren't blocked in any way anymore. I'm also not really sure why this condition survives reboots/power-cycling the router even when I change which VPN client is the one that comes up by default upon boot. Anyone have any idea what's going on there?

This is new behavior, I know from experience on older versions of the firmware that this did not occur and as soon as you brought up a new VPN the bound-devices weren't blocked in any way anymore.

The KILL-switch has always worked this way when the IP ranges overlap
e.g. if all the VPN Client configurations contain

LAN   192.168.1.0/24   0.0.0.0   vpn

then you must only enable the KILL-switch on the highest numbered VPN Client e.g. #5 will always work.

see Confused as to how to make the kill switch work

 

[Seth Harman]

The KILL-switch has always worked this way when the IP ranges overlap
e.g. if all the VPN Client configurations contain

LAN   192.168.1.0/24   0.0.0.0   vpn

then you must only enable the KILL-switch on the highest numbered VPN Client e.g. #5 will always work.

see Confused as to how to make the kill switch work

Thanks for the response. What's outlined in that post is NOT how my router has operated for quite some time and what I described in my original post is completely new behavior. For example, for the last couple of months I've been using Client 2 with no problem even though Client 1 was down and was set to block traffic if it went down. I also can't understand why firing up some VPN clients caused only some of the traffic to specific domains to not go through. I'll experiment with configuring things the way they're outlined in that post and see if that gives me the behavior I'm looking for. Cheers!

 

[Martineau]

Thanks for the response. What's outlined in that post is NOT how my router has operated for quite some time and what I described in my original post is completely new behavior. For example, for the last couple of months I've been using Client 2 with no problem even though Client 1 was down and was set to block traffic if it went down. I also can't understand why firing up some VPN clients caused only some of the traffic to specific domains to not go through. I'll experiment with configuring things the way they're outlined in that post and see if that gives me the behavior I'm looking for. Cheers!

Without providing any proof of the actual state of the RPDB rules and the ip route tables for all 5 of the VPN clients (i.e. before on pre-v384.11 firmware when it was seemingly working compared to now when the perceived KILL-switch behaviour has altered) then it will be difficult to substantiate your claim.

No matter, feel free to provide the RPDB /ip route tables if you get stuck.

P.S. I did attempt to write a crude VPN diagnostics script to highlight any 'broken' VPN Client configuration in this thread Multiple VPN clients active for different devices

 

[Seth Harman]

Without providing any proof of the actual state of the RPDB rules and the ip route tables for all 5 of the VPN clients (i.e. before on pre-v384.11 firmware when it was seemingly working compared to now when the perceived KILL-switch behaviour has altered) then it will be difficult to substantiate your claim.

No matter, feel free to provide the RPDB /ip route tables if you get stuck.

P.S. I did attempt to write a crude VPN diagnostics script to highlight any 'broken' VPN Client configuration in this thread Multiple VPN clients active for different devices

Yeah, I have no idea why the router was working in the fashion that it was and why things have now changed, but configuring it per the thread you pointed me at should allow me to do exactly what I was doing before and have it operate the way it used to which is what I'm shooting for. I'll get the other clients configured tonight and test it with only Client 5 set to block traffic if the tunnel goes down. Thanks again for the help.