Kill switch doesn't work

[SunSkyPi]

Hi All,

Just want to report back that the script worked great! Thank you so much @eibgrad! And as always thanks to Merlin for software.

Some kill switch observations:

1) When I turned off a VPN client that was set to autoboot the ks activated, but that is totally fine, I think that is by design the best I could read into the code. I unchecked the auto boot and could then access the WAN. I much rather the ks error on blocking traffic rather than letting any exposure to WAN happen, safety first.

2) In testing simultaneously with ddwrt routers (whose ks has proven bullet proof), the merlin w/script routers worked like a charm. I tested by rebooting the VPN server on the other end. What is interesting, most of the time the merlin routers would reconnect on own without having to reboot, whereas the ddwrt routers most of time would have to reboot to reconnect. A few times the ddwrt would reconnect automatically and the merlin would not---would have to reboot them. Could not ascertain a pattern why sometimes one would reconnect vs. the other, and why sometimes they would not, other than the merlins with your script were most of the time able to recconnect without having to reboot, while the ddwrt's most of the time had to reboot. Automatically reconnecting to VPN is just a nice to have, a minor effort to have to reboot, small price to pay for securely blocking WAN for safety.

3) Tested an AC68U OEM (3.0.0.4.386_43137-gc42c548, 2021-10-14), and even though no kill switch option in GUI, it seemed to work blocking WAN when VPN Server down, and also reconnect on its own, but only tested once before flashing over to merlin. With merlin on this router w/o script seemed to block WAN and reconnect to VPN every time so far. Will continue testing and report back if anything interesting happens. Wonder why the merlin AC68U ks seems to work on its own w/o the script, where the AC86Us did not?


Edit: Note did find some interesting behavior with ks script and VPN Client leak, see post #13 here:
https://www.snbforums.com/threads/3...-vpn-as-soon-as-it-connects.75411/post-723277

Much thanks to all!

merlin AC68U, AC86U,383.3.2
ddwrt Linksys WRT3200ACM, dd-wrt, 47182 (2021-08-15),
ddwrt Linksys 2500, ddwrt v3.0-r47381 mega (2021-09-08)

 

[eibgrad]

What is interesting, most of the time the merlin routers would reconnect on own without having to reboot, whereas the ddwrt routers most of time would have to reboot to reconnect. A few times the ddwrt would reconnect automatically and the merlin would not---would have to reboot them. Could not ascertain a pattern why sometimes one would reconnect vs. the other, and why sometimes they would not, other than the merlins with your script were most of the time able to recconnect without having to reboot, while the ddwrt's most of the time had to reboot. Automatically reconnecting to VPN is just a nice to have, a minor effort to have to reboot, small price to pay for securely blocking WAN for safety.

A common reason a reconnect will fail is if the OpenVPN client process dies. And that can happen if it receives a *fatal* error (e.g., AUTH FAILED event). That's why I always recommend having a watchdog process for the OpenVPN client. And why I've written watchdog scripts for both dd-wrt and Merlin. As long as the OpenVPN client is enabled, it will retry indefinitely to get restarted, even if that means resurrecting the otherwise dead OpenVPN client.

ddwrt-ovpn-client-watchdog.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

merlin-ovpn-client-watchdog.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It's unfortunate this is necessary, but I just got tired of trying to figure out every possible situation where it might recover the connection vs. when it couldn't. So now I just monitor the situation continuously w/ these scripts, and restart as necessary.

 

[DTS]

@RMerlin - thank you for your work. Your firmware is the only reason I keep using Asus routers (and buying new ones)!
@eibgrad - thank you for your killswitch script. Very helpful.

 

[audioquest]

What is the command to install watchdog script for dd-wrt
thanks

 

[octopus]

What is the command to install watchdog script for dd-wrt
thanks

Did you read in script?

 

[audioquest]

I read the comments in the script, not sure how I missed that,
Thanks for pointing that out to me

 

[DTS]

Did you read in script?

The merlin-ovpn-watchdog-74660.sh script does not have any instructions. The required differences may be minor, but I'm unfamiliar with running scripts on the router, so would appreciate to know the right way to run/install merlin-ovpn-watchdog-74660.sh. Thanks

EDIT: OK, so it looks like the Merlin watchdog script is installed exactly like the Merlin killswitch script.

 

[eibgrad]

The merlin-ovpn-watchdog-74660.sh script does not have any instructions. The required differences may be minor, but I'm unfamiliar with running scripts on the router, so would appreciate to know the right way to run/install merlin-ovpn-watchdog-74660.sh. Thanks

EDIT: OK, so it looks like the Merlin watchdog script is installed exactly like the Merlin killswitch script.

asus rt-ax88u vpn director not connected right after reboot

Hello, i have installed latest asuswrt merlin on asus rt-ax88 router. I have installed a vpn connection as vpn client with openvpn protocol. When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection. Always...

www.snbforums.com

 

[NB_8]

As promised, I've created a script to implement a kill switch based on the firewall, rather than as the router does, based on the routing tables

The contribution is much appreciated.

 

[Jack Yaz]

Just picking up the killswitch script for my own usage, thanks @eibgrad !

 

[Dejikocv]

@eibgrad Thanks for your script, it is really useful and in my case it is going to help to avoid traffic exposure.

In my environment, I have configured only one server to use the VPN but I am redirecting the port 443 from the public WAN IP to the server without using VPN.

Before I was using this:
ip rule add from 0/0 fwmark "0x8000/0x8000" table main prio 9990 # WAN fwmark
ip rule add from 0/0 fwmark "0x1000/0x1000" table ovpnc1 prio 9993 # VPN 1 fwmark
iptables -t mangle -D PREROUTING -i br0 -m iprange --src-range 192.168.1.100 -p tcp -m multiport --sport 443 -j MARK --set-mark 0x8000/0x8000

and it was working.

I have tried to make it works with your script, and I think that the reason is:

1. iptables -A $FW_CHAIN $([ "$f3" ] && echo "-s $f3") \
2. $([ "$f4" ] && echo "-d $f4") -j REJECT

so I tried different things like accept the source port 443 or marked it in the $FW_CHAIN, but I am not finding the right key. I think that the problem is the return of the response, that it is going through the VPN instead of the WAN.

Do you know what could I check to be able to redirect requests from the WAN IP?

Thanks and best regards.

 

[eibgrad]

@eibgrad Thanks for your script, it is really useful and in my case it is going to help to avoid traffic exposure.

In my environment, I have configured only one server to use the VPN but I am redirecting the port 443 from the public WAN IP to the server without using VPN.

Before I was using this:
ip rule add from 0/0 fwmark "0x8000/0x8000" table main prio 9990 # WAN fwmark
ip rule add from 0/0 fwmark "0x1000/0x1000" table ovpnc1 prio 9993 # VPN 1 fwmark
iptables -t mangle -D PREROUTING -i br0 -m iprange --src-range 192.168.1.100 -p tcp -m multiport --sport 443 -j MARK --set-mark 0x8000/0x8000

and it was working.

I have tried to make it works with your script, and I think that the reason is:

1. iptables -A $FW_CHAIN $([ "$f3" ] && echo "-s $f3") \
2. $([ "$f4" ] && echo "-d $f4") -j REJECT

so I tried different things like accept the source port 443 or marked it in the $FW_CHAIN, but I am not finding the right key. I think that the problem is the return of the response, that it is going through the VPN instead of the WAN.

Do you know what could I check to be able to redirect requests from the WAN IP?

Thanks and best regards.

Sounds to me like you're a perfect candidate for uncommenting the following line in the script.

#FW_STATE='-m state --state NEW'

Read carefully about how this features works.

 

[Dejikocv]

Sounds to me like you're a perfect candidate for uncommenting the following line in the script.

#FW_STATE='-m state --state NEW'

Read carefully about how this features works.

Thank you very much! My fault because I did not understand it correctly the first time that I read it, and I was trying to do something that it was already considered by you
It works great, and if the VPN stop, all the connections close correctly and no new ones are established.

I understand that "any pre-existing LAN->WAN connections persist unless/until they timeout/close" will mean that if I reboot the router, and the server connects to some place before running the firewall script, it will stay connected, right? I will test it, and if it I see some problem, I could try to automate a server reboot in that case, but I think that it is going to work great for me.

 

[eibgrad]

I understand that "any pre-existing LAN->WAN connections persist unless/until they timeout/close" will mean that if I reboot the router, and the server connects to some place before running the firewall script, it will stay connected, right?

Yes, that's a potential risk. But I don't know how likely that is to happen. I would *hope* the WAN is not made available until the firewall is fully established, which includes calling my script. Then again, it's not my firmware, and sometimes one's assumptions can be wrong.

 

[carver]

Spent hours to figure this out, but the "improved" kill-switch functionality is not working for me. There's no hint whether the devices will connect through vpn or wan... and within the gui I couldn't find the right switches to block wan for certain ip's.
Just registered to thank you @eibgrad for your script.
So: thank you!!

 

[bluecat]

@eibgrad

Thank you for providing the script, but I seem to have some problems to get it working, or maybe I'm misunderstanding something. After a long time, I was upgrading the FW to 386.5.2 and now discovered the problem with the Killswitch functionality, which didn't work the way it was before.

What I want to achieve:
I have one client (192.168.1.210) which should only be allowed to connect to the internet, if the VPN is on and working. No VPN, No Connection.

I configured the VPN Settings like this:

- In the Router Settings under Administration/System I turned on "Enable JFFS custom scripts and configs".
- I opened an SSH connection and installed the script you provided (without any changes) on post #12.
- After this, I rebooted the router.

To test if it's working, I went to the VPN Client and changed the username, so it couldn't login anymore to the VPN service. This turnes off the Service State and gives the message "Error - Authentication failure!". But my client (192.168.1.210) is not blocked and get's the IP address from my ISP.

Did I miss something? Are there any other (easy) ways to get just this one client blocked from accessing anything without the VPN? I don't have much knowledge of routers, so any simple advice would be really much appreciated!

Thanks,
bluecat

 

[eibgrad]

@eibgrad

Thank you for providing the script, but I seem to have some problems to get it working, or maybe I'm misunderstanding something. After a long time, I was upgrading the FW to 386.5.2 and now discovered the problem with the Killswitch functionality, which didn't work the way it was before.

What I want to achieve:
I have one client (192.168.1.210) which should only be allowed to connect to the internet, if the VPN is on and working. No VPN, No Connection.

I configured the VPN Settings like this:
View attachment 40534 View attachment 40537

- In the Router Settings under Administration/System I turned on "Enable JFFS custom scripts and configs".
- I opened an SSH connection and installed the script you provided (without any changes) on post #12.
- After this, I rebooted the router.

To test if it's working, I went to the VPN Client and changed the username, so it couldn't login anymore to the VPN service. This turnes off the Service State and gives the message "Error - Authentication failure!". But my client (192.168.1.210) is not blocked and get's the IP address from my ISP.

Did I miss something? Are there any other (easy) ways to get just this one client blocked from accessing anything without the VPN? I don't have much knowledge of routers, so any simple advice would be really much appreciated!

Thanks,
bluecat

The script changes the firewall to block the WAN based on your VPN Director rules. But simply enabling/disabling the OpenVPN client does *NOT* reinitialize the firewall! IOW, the router does NOT call the firewall service when the OpenVPN client changes, and thus my script doesn't get called either. The OpenVPN clients manage changes to the firewall *independently* of the firewall service. Any changes to the VPN Director will suffer from the same problem. That's why you either need to restart the firewall service, or better yet, reboot.

 

[bluecat]

Thank you for your fast reply. I not understand all, but I assume I still should be safe with this configuration?
- I mean, If after a restart the router and the VPN can't connect, the firewall will block access for this client.
- If the VPN works and after some time should lose connection, the killswitch from the VPN Director comes into play.
Is this correct?

 

[eibgrad]

Thank you for your fast reply. I not understand all, but I assume I still should be safe with this configuration?
- I mean, If after a restart the router and the VPN can't connect, the firewall will block access for this client.
- If the VPN works and after some time should lose connection, the killswitch from the VPN Director comes into play.
Is this correct?

Yes. As soon as the firewall is initialized, the script becomes active and provides protection.

 

[PR3MIUM]

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 386.3.2 and tried with backuped / restored setting. No luck. Factory reset and manually changing setting - still no luck to make kill switch work.
All I want is single client to be able access Internet ONLY via OpenVPN interface and if it's down then it should have no access.

I noticed in release notes that kill switch now supposed to be engaged only if OpenVPN client is set to autostart or when OpenOPN lost connection without manual intervention.
So I set OpenVPN "Automatic start at boot time" to ON, "Killswitch - Block routed clients if tunnel goes down" = ON, "Redirect Internet traffic through tunnel" = Redirector. Other OpenVPN setting are incorrect because I'm testing failed attemp to connect after reboot.
In Redirector I created two rules (one for device, second for my laptop to test it). Source = 192.168.50.2 (this is client), Remote IP = "[empty]', Interface = OVPN1. Similar rule for my laptop 192.168.50.39 to test if kill switch works.

So with these settings I supposed to have kill switch kick in and bock traffic from two IPs upon reboot and failed attempt to enable OpenVPN, right? Well, it does not work. After reboot both clients are able to access Inetrnet. What am I doing wrong? I looked at similar recent threads and I understand that logic of kill switch has changed, but it looks it got broken for me even in 386.1.x and it's not as described in current 386.3.2.

(my Asus IP is 192.168.50.1)

admin@RT-AC68U-C2E8:/tmp/home/root# ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
admin@RT-AC68U-C2E8:/tmp/home/root# ip route
216.25.247.161 dev vlan2  proto kernel  scope link
216.25.247.160/27 dev vlan2  proto kernel  scope link  src 216.25.247.174
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
127.0.0.0/8 dev lo  scope link
default via 216.25.247.161 dev vlan2

Fist i would like like to metion that Firmware 365.2 is out in the wild

Second on Asus WRT the Firewall is like a Killswitch:

Third, on Merlin the Killswitch is:

https://www.snbforums.com/attachments/1-png.40542/?hash=36eaecb92137f6bf174d5b9808aa4596

Fourth, maybe our Good wont metion you because some ppl have to many BR4iN and were thinking to much ? *JOKER FACEPALM* ?