Kill switch doesn't work

[eibgrad]

FYI. I've updated the script to v1.1.0.

Previously, any WAN rules defined w/ the VPN Director were ignored. But the built-in kill switch of the GUI always gives WAN rules precedence over any VPN rules, even those associated w/ a kill switch. I changed the script to recognize any WAN rules and do the same.

Note, this is a particularly important change for anyone who's running Merlin and the OpenVPN client(s) on a secondary router, daisy-chained behind the primary router. Access to the upstream private network of the primary router is normally possible w/ the built-in kill switch since what is actually blocked is the default gateway associated w/ the WAN, NOT the WAN itself. But my script *does* block the WAN, and so access to the upstream private network requires a VPN Director rule to that effect, and this update to the script.

 

[User101]

Hi @eibgrad .. is the previous pastbin where you put v1.1? Or where can I find it?
Many thanks!

 

[eibgrad]

Hi @eibgrad .. is the previous pastbin where you put v1.1? Or where can I find it?
Many thanks!

It's the same link.

merlin-ovpn-client-killswitch.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

 

[fuffa9]

I didn't have any problems w/ having a description. It might be something specific to your list of policies. It would help if you could post the contents of the entire variable so I can just test it exactly as you have/had it defined.

cat /jffs/openvpn/vpndirector_rulelist

Just delete it and reboot.

rm /jffs/scripts/firewall-start

@eibgrad thanks a lot, it works very well!!!

 

[audioquest]

Hi, I am a novice , would you please provide info when you have time to explain how I could implement your script.
Thanks in advance

 

[eibgrad]

Hi, I am a novice , would you please provide info when you have time to explain how I could implement your script.
Thanks in advance

The following link pretty much covers it.

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

 

[audioquest]

Okay thanks, since I only have a ms windwos 10 computer I am unsure how to implement the pastebin.com script you created

 

[eibgrad]

You need to login to the router using ssh so you don't have to use Windows to manage the script. Windows is only involved to the extent it supports your ssh client (e.g., Putty). Once connected to the router, you issue the commands I indicated within the shell to download and install the script. The idea is to do most of the work on the router itself, NOT Windows.

 

[audioquest]

I must be missing something regarding 'Once connected to the router, you issue the commands I indicated within the shell to download and install the script.
Not seeing this, appreciate the help. thanks in advance

 

[eibgrad]

Are you familiar w/ ssh? It's a terminal program. You use it to login to the router, which then presents you w/ a command line interface, similar to DOS, where you can issues commands, like ls (to list a directory), or pwd (print working directory).

P.S. I don't use Windows all that much anymore, but I believe you can run an ssh client within PowerShell.

 

[audioquest]

I haven't work with ssh . What confuses me is Once connected to the router, you issue the commands I indicated within the shell to download and install the script. I am not sure what commands your speaking of

 

[eibgrad]

Go back to that link I referenced and you'll find the following.

curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s F2GmyrCC

That will download the script, execute it, and create a file called /jffs/scripts/firewall-start, which you can then edit (if necessary) w/ the nano editor. Once you do, you can reboot and the firewall will automatically be configured appropriately to implement the kill switch (provided you followed the rest of the instructions in that link).

 

[audioquest]

thank you

 

[audioquest]

Perfect, works, really appreciate your help and guidance. I can know disable SSH and scrips in the router correct?
Also, when a new merlin version is available will I need to reinstall your script again after the firmware is installed.

 

[audioquest]

just learned, without Enable JFFS custom scripts and configs enabled the script won't work

 

[eibgrad]

Perfect, works, really appreciate your help and guidance. I can know disable SSH and scrips in the router correct?

Yes, if you wish.

Also, when a new merlin version is available will I need to reinstall your script again after the firmware is installed.

IIRC, whether a clean or dirty upgrade, the contents of /jffs are retained. But regardless, it's easy enough to repeat the installation process if necessary.

 

[SunSkyPi]

Thank you Merlin for software, and Thank you all for info on kill switch.

I have been testing with several ddwrt and merlin routers. I have quickly noticed when the VPN server goes down all the ddwrt routers kill switches work and halt all traffic, but the merlin routers fall back to WAN--danger will robinson. (The ddwrt routers need to be rebooted to reconnect to VPN, and I am thinking there is a way to have them try to reconnect automatically--but not a top priority at this time--the main thing is they block all traffic when VPN goes down--this is critical for safety, but the merlin routers do not).

I am just looking for all traffic to halt immediately when VPN is down and have zero exposure to WAN. I have no PBR, all traffic through router is to go to VPN (Redirect Internet traffic through tunnel: Yes (all)). I see on another thread, in an earlier post: Aug 16, 2021 you shared a few lines of code that would create a kill switch:

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

How is this different from script in the link you posted above in comment #26? I am just looking for the simplest way to safely block all traffic when VPN is down.

Also, I am new to this, but have used Putty before (thanks to your recommendation) so I can stumble through, how is the code above entered into router, just via Putty?

I think I understand how to input the script based on previous comments in this thread, but it seems like the short 3 lines of code would be simpler solution.

Thank you all.

Merlin routers AC86U, 386.3.2

 

[eibgrad]

Thank you Merlin for software, and Thank you all for info on kill switch.

I have been testing with several ddwrt and merlin routers. I have quickly noticed when the VPN server goes down all the ddwrt routers kill switches work and halt all traffic, but the merlin routers fall back to WAN--danger will robinson. (The ddwrt routers need to be rebooted to reconnect to VPN, and I am thinking there is a way to have them try to reconnect automatically--but not a top priority at this time--the main thing is they block all traffic when VPN goes down--this is critical for safety, but the merlin routers do not).

I am just looking for all traffic to halt immediately when VPN is down and have zero exposure to WAN. I have no PBR, all traffic through router is to go to VPN (Redirect Internet traffic through tunnel: Yes (all)). I see on another thread, in an earlier post: Aug 16, 2021 you shared a few lines of code that would create a kill switch:

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

How is this different from script in the link you posted above in comment #26? I am just looking for the simplest way to safely block all traffic when VPN is down.

Also, I am new to this, but have used Putty before (thanks to your recommendation) so I can stumble through, how is the code above entered into router, just via Putty?

I think I understand how to input the script based on previous comments in this thread, but it seems like the short 3 lines of code would be simpler solution.

Thank you all.

Merlin routers AC86U, 386.3.2

Yes, the above few lines are sufficient in most cases where your routing policy is "Yes (All)". Because even if you use the bigger script, that's all it's going to do anyway once it finds that *any* active OpenVPN client is routing ALL its traffic over the VPN. But since I don't know if and when any given user might decide to use routing policy *rules*, I generally recommend the larger script.

On a side note (just because it's interesting), I and @egc worked together on implementing the kill switch for dd-wrt! (lol). And it's based on a similar strategy used by Merlin.

Should the VPN fail for any reason, it denies access to the default gateway (unlike using a firewall rule which blocks the entire WAN). It works extremely well for dd-wrt because of the way we did it. We always install the 'prohibit default' route into the alternate routing table (10) unconditionally, and immediately on bootup. And it remains there, permanently! So how does anything ever get routed to the VPN? When the OpenVPN client connects, we split the VPN's default gateway into two routes, each of which, when combined, covers the entire public IPv4 space (0.0.0.0/0). So as long as the VPN remains up and running, those two routes are sufficient. And if the VPN fails, the routing system *automatically* pulls those two routes from the alternate routing table because the network interface they reference (tun1) is no longer valid, leaving only the 'prohibit default' rule behind. And so the client has no more access to a default route.

Merlin is a little different. If you specify autostart for the OpenVPN client and enable the kill switch, he installs the 'prohibit default' route as well within the relevant OpenVPN client routing tables. But once the OpenVPN client gets connected, he *pulls* the 'prohibit default' route from those tables and substitutes the VPN's default gateway (as a single route). Then if the VPN fails, he has to detect it and quickly reinstall the 'prohibit default' route again. For the most part, it appears to work. But I would still prefer the method we used w/ dd-wrt since it seems to me more bulletproof.

There's also a known bug w/ how the Merlin firmware deals w/ configuring the kill switch on bootup.

VPN Kill Switch Doesn't Work Temporarily Immediately After Rebooting

I'm running Merlin 386.3_2 on an RT-AC68U. I'm using the OpenVPN client with it set to connect when booted. The kill switch is enabled, and all internet traffic is set to be redirected over the VPN. I've noticed that traffic is allowed to go over the WAN immediately after rebooting for a short...

www.snbforums.com

 

[SomeWhereOverTheRainBow]

When you say you "Other OpenVPN settings are incorrect", what specifically did you purposely set incorrectly?

What I'm noticing is that w/ certain errors, particularly those so egregious that the OpenVPN process dies almost immediately (e.g., a missing CA.crt (Certificate Authority)), the kill switch can NOT be maintained. Initially the ip rules will be established, and the routing table (ovpnc1 in this case) will have a single 'prohibit default' route. But once the OpenVPN client dies, these are removed and the WAN is wide open.

One way to observe this behavior is to reboot and use ssh to run the following command to monitor the relevant data structures.

watch 'ip route show table ovpnc1; echo; ip rule'

You have to get into the router pretty quickly, before the OpenVPN process dies. And if you do, you'll see the kill switch is briefly active, but quickly dies.

Frankly, I don't know if this is the way it's supposed to work (@RMerlin would have to address that question). I suppose the argument could be made that egregious errors that would never allow the OpenVPN client to get past the basic error-checking stage, can't expect protection (presumably because the OpenVPN process is exiting normally). In the prior firmware, it seemed to work a bit differently, and the kill switch (iirc) was truly persistent, to the point it even worked when the OpenVPN client was OFF.

The ideal goal would be to have no traffic routed to the device if it is not passing through the VPN.

 

[eibgrad]

The ideal goal would be to have no traffic routed to the device if it is not passing through the VPN.

As usual, it's not always as simple as it seems.

Suppose the VPN router is a secondary device, daisy-chained behind the primary router, WAN to LAN respectively. You might very well want those clients bound to the OpenVPN client on that secondary router to have access to the *private* upstream network of the primary router, and that requires being able to route over the WAN! It's just that you don't want that secondary router to allow internet access via the primary router's WAN. If you block the WAN based on the routing system rather than the firewall, you still maintain access to the upstream private network. Using the firewall, you'd need to modify your firewall rule to make an exception for that private network.

Granted, that's the exception, not the rule. But that's why even the simple firewall rule referenced by @SunSkyPi isn't necessarily sufficient in all cases. It depends.