Weird client VPN problem that just started !

[Viktor Jaep]

I'm gone for a while, and come back to seeing a 25yr network engineering veteran and owner of a software dev company throwing a fit over a killswitch. My advice to @ichi : In lieu of going down the "I'll just create a fork" rabbithole, I do believe it's time for you to retire your Big Box Store-purchased Asus home router, and get something a bit more commercial-grade since that seems to be what you're expecting this equipment to do. My $0.02.

Welp, back to my studies!

 

[ichi]

Sorry but I've been gaslit over and over since the beta. Constantly being told that "It's supposed to block your internet, that's what killswitch does"..

I don't get why its gone from:
Activate VPN (killswitch activates automatically)
Deactivate VPN (killswitch deactivates automatically)

To:
Login to WebUI
Go to VPN settings
Set killswitch to yes
Reboot the router
Activate VPN
Deactivate VPN
Login to WebUI
Go to VPN settings
Set killswitch to no

As the process you have to follow every single time you want to use the VPN.

Explain the reasoning behind doing this change? Why is it now a 9-step, 5-minute manual process just to use the VPN with a killswitch? Every time I want to use it?

 

[ichi]

I wish him luck - he'll need it...

Not if he doesn't rewrite things that aren't broken that are working perfectly fine.
But I can imagine that doing things for no reason and ending up with a huge mess, would make things complicated.

 

[elorimer]

This implementation of the killswitch works fine with VPN Director for me. The devices that I route over the VPN I do not want to ever, for even a moment, pull anything that isn't over the VPN, whether it is active or not. If the TV connects otherwise, I have to factory reset the TV. Same with all the air conditioners, which for some reason don't work via network control in the country in which they were sold, so I have to geolocate them to another country.

 

[RMerlin]

To:
Login to WebUI
Go to VPN settings
Set killswitch to yes
Reboot the router
Activate VPN
Deactivate VPN
Login to WebUI
Go to VPN settings
Set killswitch to no

That sequence doesn't make sense. You need to log into the WebUI to activate or deactivate the VPN, so you just need to also toggle the killswitch at the same time - just a second radio button to toggle at the same time.

• Login to WebUI
• Activate VPN and Killswitch
• Hit Apply

• Login to WebUI
• Deactivate VPN and killswitch
• Hit Apply

 

[ichi]

That sequence doesn't make sense. You need to log into the WebUI to activate or deactivate the VPN, so you just need to also toggle the killswitch at the same time - just a second radio button to toggle at the same time.

• Login to WebUI
• Activate VPN and Killswitch
• Hit Apply

• Login to WebUI
• Deactivate VPN and killswitch
• Hit Apply

Then you're still not understanding the problem

You can't just go in and activate the killswitch. It doesn't work. Until you reboot the router. It's only activated on boot. Activating the killswitch after boot does nothing. You can only deactivate the killswitch after boot.

Why would you mess with it, and change was was an automated process... to a manual process? That doesn't even make sense... Now I have to login to the WebUI every single time I want to use VPN. Instead of just

echo "" | plink 192.168.50.1 -l xyzprofile -pwfile '/home/null/xyzprofilepw.txt' -P 9223 "service start_vpnclient2"
echo "" | plink 192.168.50.1 -l xyzprofile -pwfile '/home/null/xyzprofilepw.txt' -P 9223 "service stop_vpnclient2"

Just admit you butchered it. And it sucks.

 

[RMerlin]

If you use the command line instead of the webui to restart the client, then you need to also restart the vpnrouting service to update the killswitch state.

service restart_vpnrouting2

The webui does this automatically. No reboot is required.

EDIT: Also, if you are using internal commands such as service restart_vpnclient, you need to also properly update the nvram settings to both disable the client, and disable the killswitch. Manually stopping/starting a service is not the same as enabling/disabling a service. Disabling killswitch:

nvram set vpn_client2_enforce=0

Disabling the client itself - remove "2" from the list of enabled clients (comma-separated list):

nvram set vpn_clientx_eas=

The official API for end-users is through the webui. Anything done over SSH is at your own risks and peril, and require you to understand what you are doing, and how to do it properly. Just because "it worked before" does not make it right.

The reason why the killswitch design was completely rewritten is because the previous design had multiple issues. You can find quite a few discussions on these forums as to what these issues were. The new design decouplates the killswitch from the VPN service itself, which is the best way to ensure a 100% reliability in the killswitch doing its job no matter what happen. The previous design could fail under a couple of scenarios, which would leak to data lead - something a few users considered to be a critical flaw for their use cases.

 

[RMerlin]

And never forget that all of this is done using undocumented, unsupported low-level changes. These can change at any time, as the webui is the only officially supported way of doing things. You are basically using regedit to enable/disable Windows features rather than going through the Settings app.

 

[ComputerSteve]

If you use the command line instead of the webui to restart the client, then you need to also restart the vpnrouting service to update the killswitch state.

service restart_vpnrouting2

The webui does this automatically. No reboot is required.

EDIT: Also, if you are using internal commands such as service restart_vpnclient, you need to also properly update the nvram settings to both disable the client, and disable the killswitch. Manually stopping/starting a service is not the same as enabling/disabling a service.

The official API for end-users is through the webui. Anything done over SSH is at your own risks and peril, and require you to understand what you are doing, and how to do it properly. Just because "it worked before" does not make it right.

The reason why the killswitch design was completely rewritten is because the previous design had multiple issues. You can find quite a few discussions on these forums as to what these issues were. The new design decouplates the killswitch from the VPN service itself, which is the best way to ensure a 100% reliability in the killswitch doing its job no matter what happen. The previous design could fail under a couple of scenarios, which would leak to data leak - something a few users considered to be a critical flaw for their use cases.

Ok and @RMerlin has always been smart with his implementation on things. I trust what he decided to do. I can definitely see why leaks can be an issue with a vpn. I’m just making this post because I’ve noticed a weird behavior that I haven’t noticed in years of using my vpn in this same way since recently. Maybe l.. it has something to do with the killswitch but I don’t know. Maybe it has nothing to do with it.. This post was intended to bring the weird experience I’ve been having. The experience where routed device through VPN are randomly saying they don’t have internet meanwhile they do. Or that while two devices are working. Three of my other devices are saying no internet. Even rebooting those devices doesn’t fix the problem. Only disabling the vpn and remove the devices from vpn directory seems to fix the problem. Then if I add the devices back to directory they work and eventually stop again. Someone else noted they are having this problem with android tv as well.

 

[ichi]

The webui does this automatically. No reboot is required.

EDIT: Also, if you are using internal commands such as service restart_vpnclient, you need to also properly update the nvram settings to both disable the client, and disable the killswitch. Manually stopping/starting a service is not the same as enabling/disabling a service. Disabling killswitch:

nvram set vpn_client2_enforce=0

Disabling the client itself - remove "2" from the list of enabled clients (comma-separated list):

nvram set vpn_clientx_eas=

The official API for end-users is through the webui. Anything done over SSH is at your own risks and peril, and require you to understand what you are doing, and how to do it properly. Just because "it worked before" does not make it right.

The reason why the killswitch design was completely rewritten is because the previous design had multiple issues. You can find quite a few discussions on these forums as to what these issues were. The new design decouplates the killswitch from the VPN service itself, which is the best way to ensure a 100% reliability in the killswitch doing its job no matter what happen. The previous design could fail under a couple of scenarios, which would leak to data lead - something a few users considered to be a critical flaw for their use cases.

You're still not listening....

I will explain it again....

When I go into the WebUI and enable the killswitch.... It doesn't work.... Deactivating the setting in any VPN setting works. But not the other way around.

It requires a reboot of the router to work....

If I have any VPN setting that has the killswitch settting set. Then when I reboot the router - No internet connection is possible. Until I connect to the VPN. or disable that setting on the VPN settings.

 

[ichi]

And never forget that all of this is done using undocumented, unsupported low-level changes. These can change at any time, as the webui is the only officially supported way of doing things. You are basically using regedit to enable/disable Windows features rather than going through the Settings app.

That's completely incorrect.

start_vpnclient2 is exactly the same as toggling the VPN on or off in the WebUI. No settings are being changed. But that's all completely irrelevant.... You're just looking for excuses not to be wrong.
Your killswitch issues happen BEFORE I decide I want to use the VPN.... That's what you're not getting. So it has nothing to do with the issue... Since I'm not toggling the VPN for this problem to happen...

This is what it looks like when I just change the setting on a VPN config.

Sep  8 03:28:22 rc_service: httpds 2233:notify_rc start_vpnrouting2
Sep  8 03:28:22 custom_script: Running /jffs/scripts/service-event (args: start vpnrouting2)

The killswitch does not work in this state.

REBOOT THE ROUTER

This is what it looks like when I reboot the router.

May  5 15:05:11 openvpn-routing: Initializing killswitch
May  5 15:05:36 wan: finish adding multi routes
May  5 15:05:36 openvpn-routing: Applying all killswitches

Since I set the killswitch setting to yes on a VPN config before rebooting, I am now unable to connect to the internet at all. Despite no VPN active or attempting to be active....

So you cannot activate the killswitch unless you reboot.

AGAIN - IN THE ABOVE IMAGES - THE KILLSWITCH IS ACTIVE AND BLOCKING ALL OUTGOING CONNECTIONS WHILE TAKING ALL THESE SCREENSHOTS - DESPITE NO ROUTING OR VPN ACTIVE OR ATTEMPTING TO BE ACTIVE. AND I CANNOT CONNECT TO THE INTERNET IN THIS STATE.

Until I go back and set this setting back to NO. Then it immediately allows me to connect to the internet without touching anything else.

 

[ColDen]

That's completely incorrect. No changes are being made. Simply toggling the VPN on or off... That's not even adjusting a single setting.

start_vpnclient2 is exactly the same as toggling the VPN on in the WebUI. But besides that... Your killswitch issues happen BEFORE I decide I want to use the VPN.... That's what you're not getting.

This is what it looks like when I just change the setting on a VPN config.

Sep  8 03:28:22 rc_service: httpds 2233:notify_rc start_vpnrouting2
Sep  8 03:28:22 custom_script: Running /jffs/scripts/service-event (args: start vpnrouting2)

The killswitch does not work in this state.

REBOOT THE ROUTER

This is what it looks like when I reboot the router.

May  5 15:05:11 openvpn-routing: Initializing killswitch
May  5 15:05:36 wan: finish adding multi routes
May  5 15:05:36 openvpn-routing: Applying all killswitches

Since I set the killswitch setting to yes on a VPN config before rebooting, I am now unable to connect to the internet at all. Despite no VPN active or attempting to be active....

View attachment 61365

View attachment 61367

View attachment 61368


So you cannot activate the killswitch unless you reboot.

AGAIN - THE KILLSWITCH IS NOW ACTIVE AND BLOCKING ALL OUTGOING CONNECTIONS WHILE TAKING ALL THESE SCREENSHOTS - DESPITE NO ROUTING OR VPN ACTIVE OR ATTEMPTING TO BE ACTIVE. AND I CANNOT CONNECT TO THE INTERNET IN THIS STATE.

You are using the GNUton firmware version of RMerlin and should have mentionned this first...

 

[ichi]

You are using the GNUton firmware version of RMerlin and should have mentionned this first...

Rubbish. No changes to the killswitch or the VPN occurred in that version. It was entirely on your version.

Don't BS me. I've checked the code.

 

[RMerlin]

I'm done. Have one of your developers do it for you, and best of luck to both of you.

 

[ichi]

I'm done. Have one of your developers do it for you, and best of luck to both of you.

We've already fixed it.

Not that hard to maintain one model...

You're ego is obviously bigger than then pride you have in the quality of your work.

The change you were trying to implement, which was when it reboots, that it would act the same as wireguard and block connections until the VPN reconnected, could have been done in 3 lines. Rather than butchering the entire killswitch design..... Just saying......

 

[ichi]

Or did you think my spending time telling you about it, was for MY benefit...... ?

 

[ichi]

Removing this and applying it to everything, auto-start or not, was a huge error....

CHANGED: At boot time, OpenVPN killswitch will only be applied for clients set to auto-start with WAN.

 

[ichi]

You actually wrote leaks into your rewrite that weren't there before. Not sure if you realise... It's actually way worse for leaks after you touched it. You tried to fix one problem, and you created 2 more that are way worse.

 

[ichi]

But whatever. Goodluck.

 

[octopus]

But whatever. Goodluck.

Don't let the door hit you on the way out​