VPN client and killswitch

[terminator]

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]

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]

@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]

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]

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.

admin@lab-merlin1:/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

admin@lab-merlin1:/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

admin@lab-merlin1:/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]

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]

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.

#!/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.

 

[terminator]

@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?

 

[eibgrad]

@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...

#!/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.

 

[bluecat]

@eibgrad
I'm really a beginner, but would like to use your code to create my own killswitch for a specific IP. Could you tell me how I can add the script? I can open ssh into the router, but my knowledge is not much further! Thank you!

 

[eibgrad]

@eibgrad
I'm really a beginner, but would like to use your code to create my own killswitch for a specific IP. Could you tell me how I can add the script? I can open ssh into the router, but my knowledge is not much further! Thank you!

Kill switch doesn't work

It seems to me kill switch stopped working for me. I had 386.1.x FW and noticed after router reboot that my OpenVPN client is down and despite I had setting to prevent client access to Internet when VPN is down, client still had access to Internet. I could not make kill switch work so updated to...

www.snbforums.com

 

[ComputerSteve]

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

#!/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.

@eibgrad how would you run this code the opposite way to instead allow it ? would it be
#!/bin/sh
WAN_IF="$1"
iptables -I FORWARD -s 192.168.1.100 -o $WAN_IF -j ACCEPT

????

 

[ComputerSteve]

The issue with this script is it doesn't work with x3mrouting.. Is there a way to get it to work? meaning do you add this instead to vpnclient1-route-up or add a script to allow wan cause certain things you want to bypass to wan and that is the issue. Meaning when you enable the vpn I kinda want this script to go away and only run when the VPN is stopped. How can I remove this code when the vpn is started?

 

[puremind]

Unsure why all this behaviour is not sorted somewhat from the GUI, there will be loads of cases where the openvpn daemon will stop working, i.e. change password somewhere else, expiry of the account, etc.

Simply imagine your VPN subscription expires... then your vpn client(s) will go directly to the destination and there would be no warnings etc. how can that would be a preferred method to connect is defo not my option.

The method that works, thus requiring some manual touches, as pointed above, is adding to the /jffs/scripts/firewall-start file

#Deletes the rule if already existing (avoid dupes)
iptables -D FORWARD -s 192.168.1.100 -o eth0 -j REJECT


#Add rule
iptables -I FORWARD -s 192.168.1.100 -o eth0 -j REJECT

Where 192.168.1.100 is the IP you want to limit and eth0 is your WAN device

Couldn't the GUI have that option so these rules get built and added optionally to the firewall-start script for persistence and proper safety of everyone using the client vpn option?

At the end of the day, if a CIDR option is specified, the same option can be used to add the rule.

 

[Viktor Jaep]

Unsure why all this behaviour is not sorted somewhat from the GUI, there will be loads of cases where the openvpn daemon will stop working, i.e. change password somewhere else, expiry of the account, etc.

Simply imagine your VPN subscription expires... then your vpn client(s) will go directly to the destination and there would be no warnings etc. how can that would be a preferred method to connect is defo not my option.

The method that works, thus requiring some manual touches, as pointed above, is adding to the /jffs/scripts/firewall-start file

#Deletes the rule if already existing (avoid dupes)
iptables -D FORWARD -s 192.168.1.100 -o eth0 -j REJECT


#Add rule
iptables -I FORWARD -s 192.168.1.100 -o eth0 -j REJECT

Where 192.168.1.100 is the IP you want to limit and eth0 is your WAN device

Couldn't the GUI have that option so these rules get built and added optionally to the firewall-start script for persistence and proper safety of everyone using the client vpn option?

At the end of the day, if a CIDR option is specified, the same option can be used to add the rule.

When the firmware has limitations, it's up to this community to identify and build workarounds:

KILLMON - KILLMON v1.1.2 -Feb 29, 2024- IP4/IP6 VPN Kill Switch Monitor & Configurator (Now available in AMTM!)

KILLMON v1.1.2 Released February 29, 2024 Executive Summary: KILLMON is a shell script that provides additional VPN kill switch capabilities outside of the VPN kill switch functionality that is currently integrated into the Asus-Merlin Firmware. KILLMON builds on the excellent kill switch...

www.snbforums.com