Open VPN Client- Very Weird Experience

[Preskitt.man]

AC86U running 386.1_2. Playing around with the VPN client. Using OpenVPN connection to PIA server. Was trying to see what I could do with Netflix. Setup config and told router to Force Internet traffic through tunnel via Policy Rules. Setup 2 rules: My Firestick would go through VPN and my Laptop would go through VPN. No other rules. Things were working OK, until I figured I was done with my testing and turned off the VPN client.. At that point both my Laptop and Firestick lost all Internet connection. They could see the WiFi SSID, but there was no internet behind it. Tried rebooting the router - still the same condition. Went to my desktop (connected via ethernet) and went back to the VPN connection, set a rule that all devices were connected to the WAN (192.168.1.0/24 WAN). Enabled the client - and Internet came back to my WiFi. I then disabled the client - and this time the laptop and Firestick continue to have internet.

So, what seems to be the case, if you have an Open VPN client enabled with devices directed to the VPN, then disable the client; the devices that were connected to the VPN do not regain access to the internet; as if they were still being routed through the VPN client - which was now disabled. To reestablish connectivity, re-enable the VPN client, but set a rule that the devices go to the WAN; then disable the client. This would seem like a bug to me.

 

[eibgrad]

You probably have "Block routed clients if tunnel goes down" enabled, which continues even when the OpenVPN client is turned OFF! That surprised me the first time I encountered it. It seem unintutitive. But that's the way it works. You have to disable that feature before WAN access will return.

 

[MvW]

Did you enable Block routed clients if tunnel goes down?

Because if you did, losing internet connection was exactly the intention.

 

[GSpock]

check this parameter:

 

[Preskitt.man]

Well, as several have noted, that was the issue. But I disagree with the logic that if the VPN client is closed, that is equivalent to losing the internet. I have a PIA client for my laptop, and I have the kill switch enabled, yet never the less, if I turn off the client, as opposed to,lose the WiFi, I don't lose internet access till the next time I enabled the client.
In any case, have learned the implemented logic of the client, and will not make that mistake again. On new to new mistakes
Thanks all for the help.

 

[Preskitt.man]

So, there is some logic to this, BUT, far more common is youmaremdone using the VPN client and wish to terminate the connection. Since thismismanmaction that is initiated by the user, it was most likely not his intent to lose access to the internet in the process.

 

[eibgrad]

Sorry, I had to edit the post, so I deleted the original.

I agree. It would seem more logical to have OFF mean *all* settings are off and NOT in effect. But keeping the kill switch active actually has a benefit that's not obvious.

Sometimes OpenVPN providers kick users off their servers (because it's overloaded, coming down for maintenance, etc.) by killing their side of the connection. The OpenVPN client then retries indefinitely to reconnect. But the OpenVPN providers are clever. What they'll do is send an AUTH FAIL response to the client, even though the username/password and/or client cert is actually valid. That has the effect of stopping the OpenVPN server from retrying because AUTH FAIL is considered a fatal error (i.e., it's NOT going to correct itself). And now the OpenVPN process *exits*, which means the state of the OpenVPN client is now OFF!

Below I purposely specified an invalid username/password, notice the OpenVPN process immediately exited.

Mar 22 00:27:45 ovpn-client1[6413]: AUTH: Received control message: AUTH_FAILED
Mar 22 00:27:45 ovpn-client1[6413]: TCP/UDP: Closing socket
Mar 22 00:27:45 ovpn-client1[6413]: SIGTERM[soft,auth-failure] received, process exiting

I don't know if that was the reason the kill switch was implemented that way, but it's one example of where having it remain active does actually make sense.

 

[RMerlin]

Since thismismanmaction that is initiated by the user, it was most likely not his intent to lose access to the internet in the process.

The router has no way of knowing for sure if this was your action, if it was a tunnel failing to connect, to reconnect, if it was a configuration error, and so on. Hence, if the killswitch is enabled and the tunnel isn't connected, the routing rules in place will block that client.

This was a deliberate design decision, and changing this would bring as many complains as there are now, so I went with what was the safest implementation.