VPN kill switch not activating on AX88U with Asuswrt-Merlin

[copydeskcat]

Hi guys,

I've read a few other threads about this and no-one seems to have an answer. I'm using an AX88U with Asuswrt-Merlin (388.1) and ProtonVPN profiles. The VPN Client and Director works a treat - I can route/direct traffic through any devices on my network via any of the VPN profiles, and they work fine.

However, if the VPN goes down for any reason, the connection persists - and reverts back to my home IP address, which I don't want to happen on a few of the devices. I'd rather the connection just died. I have Kill switch enabled, but it doesn't seem to make any difference.

Does anyone know if there's something else I should be (or could be) doing to make this work properly?

CDC

 

[Ripshod]

I've seen the many threads regarding this so I've just been testing. I disabled YazFi and let all my IoT devices obtain their IP via dhcp and tested with the app - all good. Then I set them all up in VPN director, waited for them to stabilise and stopped the remote server. Guess what? No connection - my app can't find them. Added my mobile phone to VPN director and totally lost connection via WiFi.
Re-enabled the remote server and got my phone connection back.
So it "appears" to be working fine with the same hardware.
Can someone direct me to the VPN client logfile so I can check and post relevant clips - if needed?

 

[copydeskcat]

I don’t understand. Do you need me to post logs?

 

[Ripshod]

I've tested it to try and confirm your issue but it's working fine.
So it's likely there's a setting or plugin somewhere that's interfering.
When you flashed the 388.1 firmware you did do a factory reset after didn't you?

 

[copydeskcat]

I've tested it to try and confirm your issue but it's working fine.
So it's likely there's a setting or plugin somewhere that's interfering.
When you flashed the 388.1 firmware you did do a factory reset after didn't you?

When I flash any version, I do a full reboot/restart. Why would I need to do a factory reset - surely I’d lose all my settings etc if I did that?

 

[Ripshod]

Don't worry about that right now. Killswitch isn't working for me either.
Strange how it worked for my first test but now it isn't.
Any clues anyone?

 

[Viktor Jaep]

Don't worry about that right now. Killswitch isn't working for me either.
Strange how it worked for my first test but now it isn't.
Any clues anyone?

From what I understand (buried in another thread), the Killswitch only functions if the VPN connection is severed externally, crashes, etc. If you shut your connection down manually or programmatically, Killswitch doesn't work, and reverts to your open WAN. I'm sure someone can correct me if I'm wrong and point to the source.

 

[Ripshod]

Killswitch only functions if the VPN connection is severed externally, crashes, etc.

That's exactly what I did. I shut down the remote VPN server. Sudden disconnection. Devices were still showing connected to the internet and were still accessible via my android phone app but showed my public IP, with nothing in the logs.
I've set everything back up as it was and the killswitch in YazFi seems to work fine.
I did not kill the client - I killed the remote server.

Edited to add fuller information.

 

[copydeskcat]

That's exactly what I did. I shut down the remote VPN server. Sudden disconnection. Devices were still connected and accessible, and nothing in the logs.
I've set everything back up as it was and the killswitch in YazFi seems to work fine.

I didn’t kill the VPN manually. It just stopped working (often, if the node reaches capacity, it kicks you off). The kill switch didn’t work in this circumstance.

 

[Viktor Jaep]

I didn’t kill the VPN manually. It just stopped working (often, if the node reaches capacity, it kicks you off). The kill switch didn’t work in this circumstance.

I'm not quite sure how to explain it. I'll see if I can dig up the documentation/methodology.

EDIT: here's an interesting discussion threat that might leave more questions than answers...

Killswitch not functioning correctly

i set up policy rules strict, set block access to yes and added my subnet (192.168.4.0/24) to the rules but a small handful of websites are still loading when the vpn is not active, all load with the vpn turned on ... i'm using the latest version of merlin, any idea what could be wrong ?

www.snbforums.com

And here's another with lots more info from RMerlin himself for your reading pleasure...

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

 

[HarryMuscle]

Did you guys ever figure this out? Did the kill switch only become unreliable starting in version 388.1?

Thanks,
Harry

 

[IdleWild]

I just found out that if you turn off manually the client openVPN connection kill switch doesn't engage. I'll probably go back the previous 386 firmware I had that worked as intended. No vpn - no Internet.

 

[Viktor Jaep]

I just found out that if you turn off manually the client openVPN connection kill switch doesn't engage. I'll probably go back the previous 386 firmware I had that worked as intended. No vpn - no Internet.

From the links above... not sure if you read them:

"The recent change to only activate the killswitch if a client is in an error state is because with the previous implementation, a few users complained that stopping their client killed their entire Internet connection. Whichever way I decide to implement it, someone somewhere will complain that they want it working the other way around. So, I made a design decision to implement it the way it currently is, because this is what I felt is the most logical behaviour."

 

[IdleWild]

Yes. I saw that. Now since there's no way for me to generate the "error state" I basically have no way of knowing if it even works. So I'm leaving it to chance basically. Unless there's an easy way to test the kill switch?

 

[Viktor Jaep]

Yes. I saw that. Now since there's no way for me to generate the "error state" I basically have no way of knowing if it even works. So I'm leaving it to chance basically. Unless there's an easy way to test the kill switch?

You could always give KILLMON a whirl. I wrote it to help address the deficiency you are currently experiencing.

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

 

[IdleWild]

You could always give KILLMON a whirl. I wrote it to help address the deficiency you are currently experiencing.

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

If I use killmon should I then disable killswitch in VPN director?

 

[Viktor Jaep]

If I use killmon should I then disable killswitch in VPN director?

I personally disable it in case there's any kind of interference, but I'm pretty sure you can leave it on if you want to.

 

[IdleWild]

And another question. Regarding merlin vpn director. Say I've noticed that established openvpn client connection is not good, getting slow speed etc And usually what I would do is I would flip the switch to disable the connection and re-enable to reconnect. Now if I disable the connection I immediately get my IP exposed. What's the expected procedure now to reconnect to VPN without getting client ISP IP exposed?