Multiple VPN Clients With Kill-Switch Functionality?

[NB_8]

On my current setup I have the kill switch working. However, if I would like to disable one client in favor of another, doing so prevents me from connecting with another VPN client since the kill switch kicks in. I'm wondering if there is some way one could switch between VPN clients without needing to disable the kill switch for one in order to activate another VPN client (that would also have kill switch enabled immediately).

 

[eibgrad]

Not sure I follow. It's the *router* that connected to the OpenVPN server with its own OpenVPN client, NOT the client on the LAN that's bound to the VPN indirectly. So long as you change the routing policy to the new OpenVPN client, the kill switch from the prior OpenVPN client will NOT affect those LAN clients bound to the new OpenVPN client.

Or else I'm missing something.

 

[eibgrad]

P.S. Is this a case of wanting multiple *concurrent* OpenVPN clients active? If so, I hope you're using routing policy rules for both. If NOT, and one ends up being routed inside the other (i.e., nested tunnels), then I could see how you could have problems given the presence of a kill switch on the outer tunnel.

Anyway, you need to be far more precise in the steps that are leading to your current problems w/ the kill switch.

 

[NB_8]

Not sure I follow. It's the *router* that connected to the OpenVPN server with its own OpenVPN client, NOT the client on the LAN that's bound to the VPN indirectly. So long as you change the routing policy to the new OpenVPN client, the kill switch from the prior OpenVPN client will NOT affect those LAN clients bound to the new OpenVPN client.

Or else I'm missing something.

I should have noted in my first post that my understanding of terminology in this area is very rudimentary.

On the "VPN Status" tab there are 5 OpenVPN clients listed. On the hypothetical configuration I am referring to, two or more of those clients are set up, each to connect to a different node of the same VPN provider. Only one of these clients would be in the "On" service state at a time.

What I'd like to be able to do is to toggle one OpenVPN client to "off" and another to "on" in order to switch nodes. As I currently have it set up, however, the kill switch seems to block all traffic when the active OpenVPN client is set to "off", so I am not able to activate any others.

I'm wondering if, while retaining kill switch functionality, there is some way one could switch between OpenVPN clients without needing to disable the kill switch for one in order to activate another OpenVPN client (that would also have kill switch enabled immediately).

Hopefully my inquiry has been communicated more clearly here! If there is a better/different approach to what I am trying to accomplish I would be interested in that as well.

 

[eibgrad]

What version of AsusWRT-Merlin are you using? Prior to 386.3, the kill switch was persistent, even if you turned OFF the OpenVPN client or rebooted. But w/ 386.3 and the new VPN Director, the behavior is now different. As soon as YOU turn OFF the OpenVPN client, the kill switch is disabled as well. This is all detailed in the changelog.

 

[NB_8]

Hello, and my apologies for the late response.

When I posted a few weeks ago I was using a version prior to 386.3. However I have since updated to 386.3_2.

I understand that now the kill switch functionality will be turned off if a user turns off an OpenVPN client. Therefore I am unsure how one would go about testing whether the desired behavior would be achieved during a non user-initiated event of an OpenVPN client losing connection.

The desired behavior would be for a secondary (or tertiary, etc) OpenVPN client to establish connection if the active OpenVPN were to lose connection via a non user-initiated event. However, I have no way to initiate such a test manually, or even to tell if the kill switch is working at all since manually turning off the OpenVPN client will disable it.

Any advice would be greatly appreciated (and responded to quickly).

 

[eibgrad]

As I said before, if YOU turn off one of the OpenVPN clients in favor of another, the kill switch will be turned off on the prior OpenVPN client as well. So merely switching OpenVPN clients for a given client will NOT be hindered due to any active kill switch on the prior OpenVPN client.

But now you seem to be concerned about something new, specifically how to test for a failed OpenVPN client, and have another OpenVPN client initiated to "pick up the slack" (for lack of a better term).

To simulate the failure of any given OpenVPN client, you can simply find that process within the process table …

ps | grep [v]pnclient

… and kill it based on its process ID (left-most column).

kill <process-id>

Or just kill it "by name".

killall vpnclient1

But that's NOT going to cause another OpenVPN client to be initiated (started) in response to that event. That's just not what the router does. Until the failed OpenVPN client is restarted by YOU (or it just recovers on its own, assuming that's possible), those clients bound to that OpenVPN client will remain so, and denied internet access. To get the behavior you want would require scripting.

Something that might help wrt failed OpenVPN clients, thereby mitigating the situation, is using a watchdog process for those OpenVPN clients, since it helps recover from (in my experience) the most common cause of failures.

asus rt-ax88u vpn director not connected right after reboot

Hello, i have installed latest asuswrt merlin on asus rt-ax88 router. I have installed a vpn connection as vpn client with openvpn protocol. When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection. Always...

www.snbforums.com

 

[NB_8]

To simulate the failure of any given OpenVPN client, you can simply find that process within the process table …

ps | grep [v]pnclient

… and kill it based on its process ID (left-most column).

kill <process-id>

I'm not sure how/where the codes mentioned need to be entered to simulate an OpenVPN client failure, if anyone can point me in the right direction for further reading.

I also need to figure out what the "using the shell (ssh)" instruction means, which is part of eibgrad's excellent contribution here:

asus rt-ax88u vpn director not connected right after reboot

Hello, i have installed latest asuswrt merlin on asus rt-ax88 router. I have installed a vpn connection as vpn client with openvpn protocol. When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection. Always...

www.snbforums.com

My newness aside, it seems eibgrad's advanced watchdog script is a feature I'm guessing a number of users would very much appreciate. Something tells me we will be seeing something like it integrated into upcoming firmware iterations as well.

If I can get that script working it would solve a number of problematic scenarios. The only one I'm left wondering about is what the best way to manually switch between OpenVPN clients would be if a user does not want the kill switch to be disabled between the time that they manually stop one OpenVPN client, and start another.

 

[eibgrad]

I'm not sure how/where the codes mentioned need to be entered to simulate an OpenVPN client failure, if anyone can point me in the right direction for further reading.

There are loads of ssh tutorials on the web.

ssh is just a terminal program (client + server) that allows you low-level access to the router, for the purpose of doing things that are NOT possible via the GUI, like installing and/or running bash scripts.

Under Administration->System->Service, you have to enable the ssh server (typically LAN only). Then use an ssh client (e.g., Putty) to access that server by username/password. Once logged in, you can issue various commands, and in the case of my script, copy and paste it into the ssh terminal window where it will be executed, placing the necessary services-start script in the /jffs/scripts directory.

The only one I'm left wondering about is what the best way to manually switch between OpenVPN clients would be if a user does not want the kill switch to be disabled between the time that they manually stop one OpenVPN client, and start another.

As I've pointed out in prior threads, you could create your own kill switch that behaves more like the prior firmware, i.e., it's persistent even when the OpenVPN client isn't active, or even in the OFF state.

VPN client and killswitch

I am using AX68u on 386.3_2. I have the VPN client setup and 1 IP/machine is set to route all traffic through it. "Killswitch - Block routed clients if tunnel goes down" is checked. Now, if I change the VPN server IP address to put it in an error state, killswitch works correctly and the...

www.snbforums.com

Or else bypass the GUI completely and manage the VPNs via scripting. That gives you total control. You can start/restart/stop the OpenVPN clients, monitor them for failure, manage your own kill script(s), decide if a failed OpenVPN client should be restarted vs. abandoned in favor of another OpenVPN client, etc. Whatever you want/need.

All that said, if you are inexperienced to the point you need help learning basic tools like ssh, then obviously ALL of this is going to be a challenge. We in tech support assume a minimal level of expertise in order to achieve even the most basic improvements and modifications. That's just something you're going to have to conquer in order to achieve your goals. Like most things, the key is NOT trying to bite off more than your can chew. Solve the simplest problems first, one step at a time, even if they are imperfect.

 

[Brenneke]

Killswitch concern aside, what is your ultimate goal here?
It sounds to me like you want to be able to change your device connection from one vpn server to another, is that correct?

 

[eibgrad]

If I can get that script working it would solve a number of problematic scenarios. The only one I'm left wondering about is what the best way to manually switch between OpenVPN clients would be if a user does not want the kill switch to be disabled between the time that they manually stop one OpenVPN client, and start another.

Remember, the OpenVPN clients are prioritized, w/ #1 being the highest priority. If you configure a second "backup" OpenVPN client w/ lesser priority than the current failed OpenVPN client, and its configured to bind the same client(s) to the VPN, and it's active *before* you disable the failed OpenVPN client, there's NO CHANCE for the client(s) to access the WAN. That's only possible if you insist on stopping the failed OpenVPN client *before* activating the backup OpenVPN client.

 

[NB_8]

It sounds to me like you want to be able to change your device connection from one vpn server to another, is that correct?

Yes, you are correct. Manually changing OpenVPN clients, and not allowing any non VPN traffic while doing so (i.e. retaining kill switch functionality) was my initial goal when I started this thread. It also remains a current goal.

After starting this thread another goal also arose, which is to see what options there are for a secondary (or tertiary, etc) OpenVPN client to automatically establish connection if the active OpenVPN were to lose connection via a non-user initiated event.

Remember, the OpenVPN clients are prioritized, w/ #1 being the highest priority. If you configure a second "backup" OpenVPN client w/ lesser priority than the current failed OpenVPN client, and its configured to bind the same client(s) to the VPN, and it's active *before* you disable the failed OpenVPN client, there's NO CHANCE for the client(s) to access the WAN. That's only possible if you insist on stopping the failed OpenVPN client *before* activating the backup OpenVPN client.

I had been wondering about this. As an aside, I do not fully understand use cases for multiple OpenVPN clients being activated simultaneously, except for perhaps having multiple devices connected to different servers simultaneously.

 

[eibgrad]

I had been wondering about this. As an aside, I do not fully understand use cases for multiple OpenVPN clients being activated simultaneously, except for perhaps having multiple devices connected to different servers simultaneously.

In your case, if your intent is to have a "failover" OpenVPN client, you could activate OpenVPN client #1 and #2 w/ identical policy routing rules, but only enable the kill switch for OpenVPN client #2. If OpenVPN client #1 fails (or you intentionally stop it), those same clients simply get rerouted over to OpenVPN client #2. If it fails/stops as well, they get blocked from the WAN.

As I said before, you'd have to script a solution where OpenVPN client #2 was started only *after* a failure of OpenVPN client #1. That requires a more dynamic, event-driven solution than the router is capable of natively.