VPN Director Wiki

[Namrustler]

I'm seeking clarification of a paragraph in the VPN Director wiki.

Under Various Notes is:

• Keep in mind that the killswitch will affect how lower priority clients work. If a higher priority client triggers its killswitch, then no traffic will go through the lower priority clients. You will generally want your lowest priority client to use the killswitch if you use multiple clients.

I've read this several times over the last couple of weeks but am still unclear what it means.

I generally have the first and second VPN clients configured for PIA and StrongVPN, respectively. I have 3-4 IPs assigned to client 1 and 3-4 IPs assigned to client 2. There is no overlap in the IPs between clients 1 and 2; they are mutually exclusive. In the past, the killswitch, as far as I knew, was independent between VPN clients.

If VPN client 1 triggers the killswitch, does the statement about no traffic going through the lower priority clients (in my case VPN client 2) mean devices assigned to VPN client 2 are blocked due to the state of the killswitch on VPN client 1, or are these devices leaking out through the WAN? The latter would be highly undesirable for my requirements.

Also in the last sentence of the note says: You will generally want your lowest priority client to use the killswitch if you use multiple clients. Does this imply you shouldn't use the killswitch at all on higher priority VPN clients, or rather just make sure the lowest priority VPN client uses the killswitch?

Does the answer change if you have an overlap of IPs assigned to the clients?

Thanks.

 

[kernol]

Only the author of that paragraph and indeed of the firmware, @RMerlin , will be able to unpack it correctly.
Keen to learn from the maestro .

 

[Mikii]

Hi.
What will happen to previous nvram set commands? will they be still working? will they be replaced?
For instance, something like "nvram set vpn_client2_addr=nl.myvpn.com" ?
Thank you.

 

[ColinTaylor]

Hi.
What will happen to previous nvram set commands? will they be still working? will they be replaced?
For instance, something like "nvram set vpn_client2_addr=nl.myvpn.com" ?
Thank you.

What "nvram set" commands? The VPN client is configured through the web interface not the command line.

Any existing VPN configurations will be preserved (or migrated where necessary) when installing the new firmware.

 

[Mikii]

Hi Colin,

I am using a bunch of scripts to automatically manage some VPN settings via bash scripts. Those include commands like:

nvram unset vpn_client5_clientlist
nvram set vpn_client5_clientlist="<iPhone>10.0.200.120>0.0.0.0>VPN"
nvram commit

nvram set vpn_client2_addr=nl.myvpn.com

I would like to know whether these commands will continue working, or if any previous "nvram set" command will stop working and in that case, if there is a replacement.
Thank you

 

[ColinTaylor]

I would like to know whether these commands will continue working, or if any previous "nvram set" command will stop working and in that case, if there is a replacement.

Sorry, I don't know. The direct manipulation of the VPN nvram variables is undocumented and unsupported. If you are using bespoke scripts you will need to do your own testing to see whether they are compatible.

There are also subtle differences between the HND and non-HND routers and you haven't said what router your have.

That said, on my router vpn_client2_addr looks like it's still the same whereas vpn_client5_clientlist is obsolete and has been replaced by the VPN Director UI.

P.S. The router doesn't have bash it has sh (which is more like ash).

 

[Mikii]

Thank you for confirming this ColinTaylor. Hopefully, in due time, @RMerlin will explain how to replace obsolete codes and will show us how to change the configuration via sh.

Michele

 

[L&LD]

I do not believe that RMerlin can be expected to predict or theorize on what your scripts need to do to be compatible with the new firmware and changes therein. Particularly as you haven't stated the router you're using, nor the firmware it is currently running too.

The easiest way for you to test this is to do full backups of your router config, all your custom scripts, and your JFFS partition, along with the actual firmware you're currently using for your router, and store this away safely.

Flash the new firmware to your router, perform a full reset to factory defaults (via the WPS Button method applicable for your router) and then explore the new options available first on the new firmware, before 'blindly' putting in any old scripts, enabling old features or options, or operating with assumptions that may have changed since.

If the new firmware breaks your required use case, you can perform another full reset to factory defaults after flashing the saved (old) firmware, then restoring the backups you created above, to get back to a working setup.

Guessing and theorizing on possible interactions with the many unknowns here, while a great exercise for the mind, will not get any concrete results.

 

[Mikii]

Hi L&LD, thank you for your suggestion. Maybe with the next lockdown I'll try that )
The router is RT-AX88U.
In the meantime, I can see dozens of posts in this forum using the vpn_client?_clientlist command alone. I can wait for further development on this, I am sure other people will be interested on how to adapt their scripts too.

 

[Jack Yaz]

Sorry, I don't know. The direct manipulation of the VPN nvram variables is undocumented and unsupported. If you are using bespoke scripts you will need to do your own testing to see whether they are compatible.

There are also subtle differences between the HND and non-HND routers and you haven't said what router your have.

That said, on my router vpn_client2_addr looks like it's still the same whereas vpn_client5_clientlist is obsolete and has been replaced by the VPN Director UI.

P.S. The router doesn't have bash it has sh (which is more like ash).

custom options are in jffs now, /jffs/openvpn/vpn_clientX_custom3
where X is the client number

i think that's the main change from the client side. VPN director rules are stored in /jffs/openvpn/vpndirector_rulelist rather than an nvram variable per VPN client

 

[RMerlin]

I would like to know whether these commands will continue working

No, as vpn_client_clientlist was replaced with vpndirector_rulelist, which is stored directly in JFFS to bypass the 255 chars limit from Broadcom.

 

[Mikii]

No, as vpn_client_clientlist was replaced with vpndirector_rulelist, which is stored directly in JFFS to bypass the 255 chars limit from Broadcom.

I see. So I guess I will need to directly write on the vpndirector_rulelist file, and then do a service restart ?

would this work?

Thanks.

 

[ColinTaylor]

would this work?

We can't keep guessing what may or may not work with a bunch of scripts that we've never seen and that use an unspecified variety of nvram variables.

 

[Mikii]

I am only asking RMerlin, theoretically, if writing on the vpndirector_rulelist file, and then do a service restart could work.
As a method. Maybe the file is encrypted or checksum protected or whatever....
I am sure other people on this forum could be interested.

 

[RMerlin]

I see. So I guess I will need to directly write on the vpndirector_rulelist file, and then do a service restart ?

would this work?

Thanks.

Hard for me to say, not knowing the details of what you are doing. I recommend looking at the VPNDirector webpage source for reference on what services to restart after modifying VPN Director rules (assuming you don`t make other changes as well, in which case you might need to completely restart the client, not just reapply the rules).

Just don`t use nvram to manipulate it however. The web server has special handling code to intercept the nvram_get() calls from that webpage. You will have to directly manipulate that file (and make sure you don`t break its format).

 

[Mikii]

Thank you for pointing me to the right direction.

Michele

 

[elliottt]

Thank you for pointing me to the right direction.

Michele

I've been looking to do something similar - but mainly just for a toggle on/off of existing VPN Director rules.
The following seems to work well for my example, which pushes my Apple TV through a VPN client (for cross-region viewing):

Enable VPN Director rule:

#!/bin/sh
sed -i 's/<0>Apple TV VPN>/<1>Apple TV VPN>/g' /jffs/openvpn/vpndirector_rulelist
service restart_vpnrouting0
/jffs/scripts/service-event restart vpnrouting0

Disable VPN Director rule:

#!/bin/sh
sed -i 's/<1>Apple TV VPN>/<0>Apple TV VPN>/g' /jffs/openvpn/vpndirector_rulelist
service restart_vpnrouting0
/jffs/scripts/service-event restart vpnrouting0

Thanks to @RMerlin for your suggestion of checking out the VPNDirector page source - and for implementing this feature alongside all the others!

 

[Mikii]

Thank you very much @elliottt for confirming this, this is exactly the kind of confirmation I was after!

Cheers,

 

[Charles Wilkinson]

Hey guys,
I spent a load of time playing with this building on the ideas above and have created a script for managing VPN Director rules that has the following benefits:

1. It lets you specify destination hosts that you want to route over the VPN (for all local devices). Want to send all traffic to netflix.com via the VPN. You got it!
2. It also uses iptables to achieve the 'kill switch' functionality for such rules.

You can find the write-up and the script(s) here: https://charleswilkinson.co.uk/2021/11/21/asus-merlin-route-via-vpn-for-specific-destination-hosts/
Let me know what you think - my shell scripting is a bit rusty!