VPN client and killswitch

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

terminator

Regular Contributor
I am using AX68u on 386.3_2.

I have the VPN client setup and 1 IP/machine is set to route all traffic through it. "Killswitch - Block routed clients if tunnel goes down" is checked.
Now, if I change the VPN server IP address to put it in an error state, killswitch works correctly and the intended client is not allowed to access internet. In this scenario the VPN Client "Service State" is ON but there is an error connecting.

But if router restarts and the VPN client's "Service State" is OFF (happened right after the 386.3_2 upgrade) or another error condition hits that turns the VPN client's Service State OFF (like invalid username/password, etc), then in that case the killswitch does not kick in and the client is allowed to use the regular internet.

Is this the working as designed behavior? If so, any options to activate the killswitch when the VPN client's Service State is OFF due to whatever error condition?
 

eibgrad

Very Senior Member
Prior to 386.3, the kill switch was persistent, even when the OpenVPN client was OFF. According to the changelog and starting w/ 386.3 and VPN Director, @RMerlin changed it to NOT be persistent when OFF. So the behavior you're currently seeing is as expected.

- Manually stopping a client will remove the kill switch. It will now only be applied at boot time (if client was set to start at boot), or if the tunnel is disconnected through a non-user event

Users had mixed feelings about the prior behavior. Many felt that if the OpenVPN client is configured as OFF, none of its settings/options should be active, by definition. I guess Merlin finally agreed and made the change. But it should still work at boot time if the client is configured to auto start.

I don't know of anyway to returning to the prior behavior short of installing the prior firmware.
 

terminator

Regular Contributor
@eibgrad - the information helps. Thank you so much.
@RMerlin - Anyway to add a flag "Persist when off" or something by any chance? As you can see from the above use case, it was off after restart, the client connected and did torrenting and now I might get a letter from the ISP :(
 

RMerlin

Asuswrt-Merlin dev
Anyway to add a flag "Persist when off" or something by any chance?
I don`t plan to. Waste of nvram space for 99.9% of users, the solution is to set the client to start automatically.
 

eibgrad

Very Senior Member
Using 386.3_2, I tried setting auto start and purposely providing an invalid username, then rebooted. Once rebooted, the OpenVPN client does turn OFF, since an AUTH FAILED error is consider fatal and kills the OpenVPN process. But if I dump the RPDB and routing tables, I see the kill switch is active.

Code:
[email protected]:/tmp/home/root# ip rule
0:    from all lookup local
10210:    from 192.168.1.7 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

[email protected]:/tmp/home/root# ip route
192.168.63.1 dev vlan2  proto kernel  scope link
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.63.0/24 dev vlan2  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2  metric 1
127.0.0.0/8 dev lo  scope link
default via 192.168.63.1 dev vlan2

[email protected]:/tmp/home/root# ip route show table ovpnc1
prohibit default

IOW, my rule which limits the VPN to 192.168.1.7 is being routed through the ovpnc1 table, which is blocking the default route.

Now if I instead specify a bogus server IP and reboot, the OpenVPN client does NOT turn OFF (which makes sense), but the kill switch continues to be active (of course, I never get connected to the OpenVPN server).

So at least for me, it seems to be working as advertised. Not sure if we have a complete understanding of the OP's problem. Perhaps there's something different we're missing.
 

terminator

Regular Contributor
Thanks, I have hit certain conditions which turns the VPN client OFF which turns the killswitch off even when auto start is enabled. I can't imagine I would be the only one hitting these conditions. The first time it happened is right after I applied the firmware upgrade. The only reason I caught it was because the downloads that are supposed to go through the VPN were way fast! :) The second time it happened when the VPN server for some reason sent back "credentials invalid" (I guess this could also happen if you change your credentials via a browser and forget to update them?). I used to be a programmer/developer so can understand that there might some paths where this can happen where he conditions have not been gracefully handled (with if statements). There might be other situations where the Client could turn off for other VPN providers. The only way to be 100% sure is if killswitch applied all the time. I don't really know what error conditions the VPN server will send (other than invalid IP that we can easily test) that will cause the client to turn OFF.
 

eibgrad

Very Senior Member
Well you could always create your own kill switch. How difficult that might be depends on the complexity level of your routing policy rules. In the best case, where *all* the clients are routed over the VPN, it's pretty simple. You just block all those same clients from the WAN w/ the following firewall-start script.

Code:
#!/bin/sh
WAN_IF="$1"
iptables -I FORWARD -o $WAN_IF -j REJECT

In fact, before the VPN Director came along, the kill switch didn't work unless you were using routing policy. For anyone relying on the VPN's default behavior, which routes everything over the VPN, the above was a possible solution.
 
Last edited:

eibgrad

Very Senior Member
@eibgrad that might work. I am not proficient in firewall rules. Can this be easily changed to do it for only one IP all traffic?

If you mean you only have one IP bound to the VPN...

Code:
#!/bin/sh
WAN_IF="$1"
iptables -I FORWARD -s 192.168.1.100 -o $WAN_IF -j REJECT

Now only that one IP is denied access to the WAN.

Notice by using your own kill switch, you can be selective in what is blocked from the WAN. IOW, you might be ok w/ having some source IPs which are bound to the VPN, fall back to the WAN when the VPN fails, but want others blocked. That's something the GUI's kill switch can't do! With the GUI, it's all or nothing wrt what's bound to the VPN.

Also, you don't have to block the WAN based solely on source IP. You could block the WAN based on the client's MAC address, or even ports. Whatever makes sense. In short, you can be as creative as you want/need to be.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top