Kill switch doesn't work

[Viktor Jaep]

Killswitch works as it should, it doesn't block if you turn off vpn manually.
It was changed after ONE person complained that he couldn't access the internet after turning off the vpn client.
Only if you ssh command "service stop_vpnclient(x)" the killswitch works
If you ask me, the killswitch should always block access to the internet.

I thought it was the other way around, @octopus... as in, if the vpn client gets killed due to an error, then the killswitch works. But if you issue the service stop command, then the killswitch turns off in order to let traffic through?

 

[octopus]

I thought it was the other way around, @octopus... as in, if the vpn client gets killed due to an error, then the killswitch works. But if you issue the service stop command, then the killswitch turns off in order to let traffic through?

When you turn off the client with off/on, the killswitch does not work.

 

[Viktor Jaep]

Hello,
Apologies if it's been asked before. But I couldn't figured out what was wrong.
Same as a few others, I'm trying to control some of my server accessing internet only when OpenVPN is on.
I'd like to the router to block them from accessing internet as soon as I manually turn off the OpenVPN client.

I'm using the asus-merlin firmware version 3004.388.5 on AX86U
1. set Enable JFFS custom scripts and configs to yes
2. Redirect Internet traffic through tunnel = VPN Director (policy rules)
3. Killswitch - Block routed clients if tunnel goes down = yes
4. Automatic start at boot time = yes
5. Add policy server1 192.168.1.120 0.0.0.0/0 ovpn1
6. SSH to the AX86U, download the killswitch and watchdog scripts, I can see both installed successfully. after that i have following files in the /jffs/scripts folder

-rwxrwxrwx 1 admin root 154 Dec 19 18:01 firewall-start
-rwxrwxrwx 1 admin root 3704 Dec 19 18:23 merlin-ovpn-client-killswitch.sh
-rwxrwxrwx 1 admin root 1641 Dec 19 18:22 merlin-ovpn-client-watchdog.sh
-rwxrwxrwx 1 admin root 172 Dec 19 17:53 services-start

7. reboot

After reboot, the testing shows the server 192.168.1.120 will still be able to access internet after I turn off ovpn1
I read the syslog and saw the killswitch was evoked and the reject statement was added to the iptables. but why it didn't block my server's traffic.

iptables -A ovpnc_block_wan -s 192.168.1.120 -d 0.0.0.0/0 -j REJECT
merlin-ovpn-client-killswitch[19833]: + iptables -I FORWARD -i br+ -o eth0 -j ovpnc_block_wan

I'm not very familiar with Linux's ip route table, I noticed the killswitch runs after the router reboot, it added the lines above into the route table.
But I can't get the server internet access traffic blocked after I shutdown the OVPN1.

Any thoughts?

Elac

I believe @eibgrad's script uses the VPN Director to determine what should/shouldn't be blocked. I didn't take that approach with KILLMON, because I found that a confusing way to go. In KILLMON, you can specify a single IP, a range of IPs or everything. It also has a mechanism to add the iptables rules back on a reboot as well. Just know, that stopping/starting VPN, or other firewall-related services that impact the iptables could have an effect on the KILLMON rules, so it needs to be watched carefully. I don't have a mechanism in there to automatically refresh and apply the rules if the rules appear broken as of yet. Give it a shot to see if this gives you better results?

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

 

[Viktor Jaep]

When you turn off the client with off/on, the killswitch does not work.

But if you do a service stop, then the killswitch does work? I thought that was effectively doing the same thing as the on/off switch?

 

[octopus]

But if you a service stop, then the killswitch does work?

Yes

I thought that was effectively doing the same thing as the on/off switch?

No

 

[Viktor Jaep]

Yes

No

Interesting tidbit. Thanks!

 

[elac]

Killswitch works as it should, it doesn't block if you turn off vpn manually.
It was changed after ONE person complained that he couldn't access the internet after turning off the vpn client.
Only if you ssh command "service stop_vpnclient(x)" the killswitch works
If you ask me, the killswitch should always block access to the internet.

Hi Octopus,

Thank you for the explanation!
Any chance we can get the previous version (the one that can stop my server's internet access without need to enter a cli command)?

Elac

 

[octopus]

Hi Octopus,

Thank you for the explanation!
Any chance we can get the previous version (the one that can stop my server's internet access without need to enter a cli command)?

Elac

You can read here how it was explained at the time.

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

 

[elac]

I believe the code in post #12 was not the original one. it has been updated by the author.

 

[bibikalka]

You can read here how it was explained at the time.

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

So is it a fair conclusion that the way kill-switch works now is more simple to maintain that the more restrictive block all version? Looking through other places such as Reddit it seems stand alone VPN clients also suffer from occasional malfunctions with kill-switch. Another issue is never ending DNS/IP6 leaks out there with VPN. Total 100% VPN function or dead internet otherwise via kill-switch is still sort of tricky at times.


KILLMON is a great tool around the present issues. One should simply assign VPN clients static IP addresses, and then manage that range with KILLMON.

Implementation wise, it's probably easier (and uglier) to just daisy chain routers, and have a dedicated VPN router with its own subnet if a bunch of clients must go through VPN.

 

[bibikalka]

So here are a couple of interesting datapoints to keep the conversation going.

First, the new kill-switch functionality is such that sometimes it does not kill the connection if VPN is down (Sept 2021) - the issue that is causing a bit of disconnect relative to the prior expectations:

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

Second, here is a description of main 2021 Merlin milestones (Dec 2021):

2021 State of the router

Hi everyone, I debated whether or not to do a yearly report like I used to do. I skipped doing it last year as after actually writing it, it felt like I didn't really have anything worthwhile to say, so I didn't post it. But some users then started asking "where is it?", so I guess there are...

www.snbforums.com

"... another task of code rewrites related to OpenVPN. This paved the way to the introduction of VPN Director, which was a redesign of the existing policy-based routing. This new feature made management of routing policies simpler and more intuitive by being centralized into one single location, and they were also able to resolve a few long-standing issues by leveraging the complete overhaul of how OpenVPN routing was handled, by moving it outside of OpenVPN itself and into the firmware code."

It feels there is really a need for community to advance a proposal for nuclear kill switch that always kill any non-VPN traffic (the classical meaning of killswitch), and does not mess up the simplicity of VPN Director as implemented.

Looking at the present VPN director interface, it has this:

Add new rule ( Max Limit : 199 )

​

Enable	Description	Local IP	Remote IP	Iface	Edit

​

router speed test

192.168.1.178

OVPN1

And then there is KILLMON script that we all know and love, and which also operates for specific IPs to provide a nuclear kill-switch:

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

So what's interesting is that killswitch actually does not seem to belong in the VPN client section.

​

Accept DNS Configuration	Disabled Relaxed Strict Exclusive
Redirect Internet traffic through tunnel	NoYes (all)VPN Director (policy rules)
Killswitch - Block routed clients if tunnel goes down	Yes No

In particular, if I have Redirect Internet traffic through tunnel set to VPN Director, then both DNS Configuration and Killswitch have to move VPN Director level as well, under device specific rules. As long as a VPN client establishes a connection, the job in that section is done. VPN client cannot have a kill switch - since it's not linked yet to any particular devices. At this point of "VPN client" we have a VPN going between Asus router and some remote VPN server. There is nothing to kill yet.

VPN director role is then to tell a client to use a particular VPN interface, and then this very section could have buttons to set kill-switch for that device if the interface is not available, and to force DNS to be exclusive too.

I have my router reboot itself daily, and it seems VPN Director manages to link a specific device to a particular VPN tunnel without an issue, and then KILLMON manages to ensure that there are no traffic leaks after reboot has occurred. So it might be possible to actually have all this functionality under the same roof in VPN Director tab.

Thoughts?

 

[Viktor Jaep]

So here are a couple of interesting datapoints to keep the conversation going.

First, the new kill-switch functionality is such that sometimes it does not kill the connection if VPN is down (Sept 2021) - the issue that is causing a bit of disconnect relative to the prior expectations:

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

Second, here is a description of main 2021 Merlin milestones (Dec 2021):

2021 State of the router

Hi everyone, I debated whether or not to do a yearly report like I used to do. I skipped doing it last year as after actually writing it, it felt like I didn't really have anything worthwhile to say, so I didn't post it. But some users then started asking "where is it?", so I guess there are...

www.snbforums.com

"... another task of code rewrites related to OpenVPN. This paved the way to the introduction of VPN Director, which was a redesign of the existing policy-based routing. This new feature made management of routing policies simpler and more intuitive by being centralized into one single location, and they were also able to resolve a few long-standing issues by leveraging the complete overhaul of how OpenVPN routing was handled, by moving it outside of OpenVPN itself and into the firmware code."

It feels there is really a need for community to advance a proposal for nuclear kill switch that always kill any non-VPN traffic (the classical meaning of killswitch), and does not mess up the simplicity of VPN Director as implemented.

Looking at the present VPN director interface, it has this:

Add new rule ( Max Limit : 199 )

​

Enable	Description	Local IP	Remote IP	Iface	Edit

​

router speed test

192.168.1.178

OVPN1

And then there is KILLMON script that we all know and love, and which also operates for specific IPs to provide a nuclear kill-switch:

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

So what's interesting is that killswitch actually does not seem to belong in the VPN client section.

​

Accept DNS Configuration	Disabled Relaxed Strict Exclusive
Redirect Internet traffic through tunnel	NoYes (all)VPN Director (policy rules)
Killswitch - Block routed clients if tunnel goes down	Yes No

In particular, if I have Redirect Internet traffic through tunnel set to VPN Director, then both DNS Configuration and Killswitch have to move VPN Director level as well, under device specific rules. As long as a VPN client establishes a connection, the job in that section is done. VPN client cannot have a kill switch - since it's not linked yet to any particular devices. At this point of "VPN client" we have a VPN going between Asus router and some remote VPN server. There is nothing to kill yet.

VPN director role is then to tell a client to use a particular VPN interface, and then this very section could have buttons to set kill-switch for that device if the interface is not available, and to force DNS to be exclusive too.

I have my router reboot itself daily, and it seems VPN Director manages to link a specific device to a particular VPN tunnel without an issue, and then KILLMON manages to ensure that there are no traffic leaks after reboot has occurred. So it might be possible to actually have all this functionality under the same roof in VPN Director tab.

Thoughts?

My thoughts? Someone here loves to chat about killswitches!

LOL... nice write-up, @bibikalka -- really great info and observations! It certainly is an interesting problem. I do have some plans on enhancing KILLMON here in 2024... so if you have any good suggestions on what might help make it even better, please don't hesitate to share your thoughts!

 

[bibikalka]

My thoughts? Someone here loves to chat about killswitches!

LOL... nice write-up, @bibikalka -- really great info and observations! It certainly is an interesting problem. I do have some plans on enhancing KILLMON here in 2024... so if you have any good suggestions on what might help make it even better, please don't hesitate to share your thoughts!

Ideally, I'd like to see some of KILLMON functionality directly in the firmware itself, in VPN Director, under Add new rule ( Max Limit : 199 )

Perhaps, there is some room for collaboration with @RMerlin ??? - Nah, probably too far fetched ...

A simple use case is 1 device - specific VPN client, no IP6, nuclear kill switch, exclusive DNS. This use case can be easy for a casual user!!!