RT-AX86U VPN Problems - Removing Client from VPN

[Ydnaroo]

I set up a new RT-AX86U last weekend and I'm making changes to the basic setup and learning to find my way around the router. Using Merlin 386.2_4.

I'd successfully setup a VPN client and directed 2 devices with fixed IPs to use the tunnel through the routing panel at the bottom of the VPN client page. All worked as expected.

I now need to stop one of devices, a windows laptop, from using the tunnel and connect through the WAN. I turned off the VPN connection and removed the laptop from the routing panel at the bottom of the VPN page, saved the setting which then showed the laptop removed and VPN turned off. I restarted the laptop but could not connect to the WAN (WiFi connected), I restarted the router and laptop but still no joy.

If I look in the system log I see the following which I assume is the problem: (The MAC address was that of the laptop.)

May 28 11:20:18 kernel: CONSOLE: 339948.973 wl1.0: wlc_send_bar: for aa:bb:cc:dd:ee:ff seq 0x1 tid 4
May 28 11:20:18 kernel: CONSOLE: 339949.135 wl1.0: wlc_send_bar: for aa:bb:cc:dd:ee:ff seq 0x1 tid 2
May 28 11:20:38 kernel: CONSOLE: 339968.453 wl1.0: wlc_send_bar: for aa:bb:cc:dd:ee:ff seq 0x1 tid 3

I've now turned the VPN back on without the rule telling the laptop to use the VPN and the laptop now connects to the internet using the WAN which is what I want but there is a problem somewhere, I assume the blocking if VPN down rule or policy rule is still being applied to the laptop even though it's not using the VPN.

Can anyone help sort this out?

 

[GSpock]

I think that you should have not turned the VPN OFF, but simply remove the PC from the list of the "rules for routed clients" and then hit the apply button ... then the laptop would have had directly access back to the WAN.

 

[Ydnaroo]

I think that you should have not turned the VPN OFF, but simply remove the PC from the list of the "rules for routed clients" and then hit the apply button ... then the lapop would have had directly access back to the WAN.

Yep, thanks, that's how I've ended up with it working. I'm thinking what'll happen if the VPN goes down for a period or I end my subscription. Maybe it'll have to be a router reset? (Or change the laptop IP.)

 

[GSpock]

... Maybe it'll have to be a router reset? (Or change the laptop IP.)

I would say reboot rather than a reset. Changing laptop IP would make it also. But I am almost sure some VPN gurus around this forum will have a better solution ... ?
BTW, the messages you show as extract from syslog are not showing this issue: these are debug messages from the wireless driver ...

 

[eibgrad]

Sounds like a case of having the kill-switch enabled on the VPN (Block routed clients if tunnel goes down=yes).

This is one of those rare instances where a setting remains persistent, even if the VPN is disabled, which causes lots of confusion. Because the only way to reset it is to turn the feature OFF before disabling the VPN, and rebooting. Anything less and you risk unexpected behavior.

 

[Ydnaroo]

Sounds like a case of having the kill-switch enabled on the VPN (Block routed clients if tunnel goes down=yes).

This is one of those rare instances where a setting remains persistent, even if the VPN is disabled, which causes lots of confusion. Because the only way to reset it is to turn the feature OFF before disabling the VPN, and rebooting. Anything less and you risk unexpected behavior.

Thanks for that. I'll try to remember for the future.

 

[Martineau]

Because the only way to reset it is to turn the feature OFF before disabling the VPN, and rebooting.

Clearly misleading and incorrect - simply manually remove the single 'prohibit' iptables rule or manually execute vpnrouting.sh with the appropriate args/NVRAM parameter etc. (remember routing table 254 == main) and to clarify, manipulation of RPDB rules and/or iptables does not mandate/require a reboot.