How to reconnect device after OpenVPN kill switch

[jlevy]

I recently setup my first VPN Client on my Asus AC86U router which is running Merlin. I have multiple OpenVPN clients configured which connect to different servers; I have no intention of having more than one active/on at a time. Each client has the kill switch enable and policies to send certain devices through the VPN. While I'm learning how to manage this VPN stuff (I'm a noob to it), I am only sending my phone and the xbox through the VPN as my wife would not appreciate all the interruptions on her devices while I learn.

I decided to test switching from one client to another and see if it would behave as I expected... so, I turned off the initial client and turned on a different client for a different server. Immediately...

my phone stopped getting any data through. I wonder if this somehow triggered the kill switch. I have duplicated this on another device and saw the same behavior so it's not just happening to my phone. It does seem to effect ONLY the devices that were configured to use the VPN... all other devices continue to get data through the WAN connection.

The only thing I've found to fix this is to reset the router and reconfigure the VPN client. I've read a number of threads on this forum that seemed very similar but they usually surpass my technical abilities by the 2nd word. Does anyone know how I can change VPN clients and gracefully recover?

Note: I am really quite ignorant to a lot of this stuff... I don't know how to execute command line operations on my router... so start from the beginning, please.

 

[eibgrad]

You shouldn't normally be switching OpenVPN clients on an active system. For one thing, clients often have long-standing transactions/connections, and when you change the configuration at the routing level (which is what the VPN does), it can play havoc w/ those transactions. Some client devices/apps will recover relatively quickly, others not so much. You basically have to wait for connection tracking to flush out the old ones before new ones based on the new routing will be honored.

Again, that's why I say, it's not really *normal* for the routing system to be changed on a running system. You're supposed to configure for a certain configuration from bootup and leave it alone. And if you don't, then you can expect bad things to sometimes happen.

Just to give a real world example of my own. I'm running an OpenVPN client as well. And for stealthy reasons, I've configured it to automatically restart every four (4) hours, so it can use a different server. But that plays havoc w/ my VOIP adapter since it maintains its own OpenVPN connection back to the VOIP provider! Eventually, perhaps after 5-10 minutes, it realizes there's a problem and it recovers. But in the meantime, the landline is out of commission. So to correct the problem, I had two choices; do NOT restart the OpenVPN client every four hours, OR, use PBR (policy based routing) to exclude the VOIP adapter from the VPN. I chose the latter.

 

[jlevy]

You shouldn't normally be switching OpenVPN clients on an active system. For one thing, clients often have long-standing transactions/connections, and when you change the configuration at the routing level (which is what the VPN does), it can play havoc w/ those transactions. Some client devices/apps will recover relatively quickly, others not so much. You basically have to wait for connection tracking to flush out the old ones before new ones based on the new routing will be honored.

Again, that's why I say, it's not really *normal* for the routing system to be changed on a running system. You're supposed to configure for a certain configuration from bootup and leave it alone. And if you don't, then you can expect bad things to sometimes happen.

Just to give a real world example of my own. I'm running an OpenVPN client as well. And for stealthy reasons, I've configured it to automatically restart every four (4) hours, so it can use a different server. But that plays havoc w/ my VOIP adapter since it maintains its own OpenVPN connection back to the VOIP provider! Eventually, perhaps after 5-10 minutes, it realizes there's a problem and it recovers. But in the meantime, the landline is out of commission. So to correct the problem, I had two choices; do NOT restart the OpenVPN client every four hours, OR, use PBR (policy based routing) to exclude the VOIP adapter from the VPN. I chose the latter.

I really appreciate your input. Based on this, I ran a test in which I switched the active/enabled VPN client and, after my phone lost it's data, I let things sit for about 20 minutes. After that duration, my phone did not and was not able to "recover". It seems I had to delete and setup the VPN clients before I could get data flowing again to my phone.

I don't really understand what is happening and, as long as I don't have to switch clients often, this won't really bother me. But... if anyone knows a good way to get my devices to "follow" the router's VPN clients, "I'm all ears".

 

[eibgrad]

As better solution than simply letting the phone sit there is to disable its wifi, then reenable it.

In some cases, you may need to reboot the device, perhaps the router too! Just depends. On more than one occasion, it got so bad, I found it easier to TURN OFF THE POWER TO THE ENTIRE HOUSE then run around to all my devices to get everything back in working order!

 

[L&LD]

@eibgrad, when I asked for access to the main power panels at a few customers homes, they were more than a little concerned.

Good thing the new network ran so stable for them afterward.