What's new

vpnmgr Randomizer Script for Nordvpn

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Viktor Jaep

Part of the Furniture
Hi Everyone,

I created a modified script (by heavily borrowing from our wonderful community on this) that would randomly connect to 1 of 5 different configured NordVPN endpoints. I'm not going to lie, there continue to be some issues where it gets into an endless "unable to connect" loop, but I'm thinking it's mostly either due to NordVPN not providing the right info, or vpnmgr not completing its refresh correctly? It's basically the same behavior I was seeing if I let vpnmgr reset my connection on a regular basis. @Jack Yaz said he was going to revisit this at a later point when he's going some more time to dedicate to coding/troubleshooting.

So, in vpnmgr, I have 5 different vpnclient configurations set up identically, but each one pointing to a different city... ie. Atlanta, Chicago, etc...

Screenshot 2021-12-29 10.39.39.png


Here's the vpnon.sh script I modified... credits to those who worked on this from this thread: https://www.snbforums.com/threads/vpn-on-off-via-cron-script.55022/ I tried adding some pauses, hoping that vpnmgr may need some time when it comes to querying the NordVPN APIs for updated server lists for these city locations, but it does not seem to have any effect. I'm using a cron job to call this script 1x a week at this point, just to give me some more stability for longer.

Code:
#!/bin/sh

service stop_vpnclient1
service stop_vpnclient2
service stop_vpnclient3
service stop_vpnclient4
service stop_vpnclient5

sh /jffs/scripts/service-event start vpnmgrrefreshcacheddata
sleep 10
sh /jffs/scripts/service-event start vpnmgr
sleep 10

# Generate a number between BASE and N, ie.1 and 3 to choose which vpnclient is started
let N=5     #number of configured vpnclients to choose from, max 5 on Asus 86U
let BASE=1  #random numbers start at BASE upto N, ie. 1..3

RANDOM=$(awk 'BEGIN {srand(); print int(32768 * rand())}')
option=$(( RANDOM % N + BASE ))

case ${option} in

    1)
        service start_vpnclient1
        logger -t VPN client1 "on"
    ;;

    2)
        service start_vpnclient2
        logger -t VPN client2 "on"
    ;;

    3)
        service start_vpnclient3
        logger -t VPN client3 "on"
    ;;

    4)
        service start_vpnclient4
        logger -t VPN client4 "on"
    ;;

    5)
        service start_vpnclient5
        logger -t VPN client5 "on"
    ;;
esac

exit 0

The errors I still seem to be getting stem from when vpnmgr query the NordVPN API and try to establish a new connection. I will get an endless loop where it tries to connect back to NordVPN unsuccessfully. Here's a snippet of what I see in the logs:

Code:
Dec 29 11:03:42 ovpn-client3[6332]: write UDP: Operation not permitted (code=1)
Dec 29 11:04:28 ovpn-client3[6332]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 29 11:04:28 ovpn-client3[6332]: TLS Error: TLS handshake failed
Dec 29 11:04:28 ovpn-client3[6332]: SIGUSR1[soft,tls-error] received, process restarting
Dec 29 11:04:28 ovpn-client3[6332]: Restart pause, 5 second(s)
Dec 29 11:04:33 ovpn-client3[6332]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 29 11:04:33 ovpn-client3[6332]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 29 11:04:33 ovpn-client3[6332]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 29 11:04:33 ovpn-client3[6332]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 29 11:04:33 ovpn-client3[6332]: TCP/UDP: Preserving recently used remote address: [AF_INET]37.120.215.83:1194
Dec 29 11:04:33 ovpn-client3[6332]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 29 11:04:33 ovpn-client3[6332]: UDP link local: (not bound)
Dec 29 11:04:33 ovpn-client3[6332]: UDP link remote: [AF_INET]37.120.215.83:1194
Dec 29 11:04:33 ovpn-client3[6332]: write UDP: Operation not permitted (code=1)
Dec 29 11:04:35 ovpn-client3[6332]: write UDP: Operation not permitted (code=1)
Dec 29 11:04:39 ovpn-client3[6332]: write UDP: Operation not permitted (code=1)

If anyone has any suggestions on how to make this better, or more reliable, or see where I'm going wrong... I'm all ears. ;)

Thanks!
 
Last edited:
Admittedly, I'm NOT familiar w/ the vpnmgr script. I've only given it a cursory glance. And it seems it relies on the NordVPN API to choose the server. But I don't know if that necessarily means it is guaranteed to be available. Like I've told ppl when using OpenVPN normally via the GUI, I consider it a mistake to specify only *one* server in your OpenVPN client configuration for this very reason. If by chance that server isn't available (down for maintenance, overloaded, etc.), you're stuck. You've given the OpenVPN client no other option than to retry endlessly (or whatever you've specified for max retries). IMO, you should *always* provide at least three (3) servers (in the form of additional remote directives) to any OpenVPN client to minimize the risk of having the OpenVPN client fail to get connected.


It's either that, or else the script should not just blindly assume the OpenVPN client actually gets connected. Instead, it should follow-up the (re)start w/ a check that the connection completed. Admittedly OpenVPN doesn't make that easy, and why I prefer to provide multiple servers (thus let OpenVPN itself manage that process). But I assume that would undermine the usefulness of the vpnmgr (i.e., that script is purposely showing preference to a single server). If so, that may be its fatal flaw.
 
Last edited:
to rely on the NordVPN API to choose the server. But I don't know if that necessarily means it is guaranteed to be available. Like I've told ppl when using OpenVPN normally via the GUI, I consider it a mistake to specify only *one* server in your OpenVPN client configuration for this very reason. If by chance that server isn't available (down for maintenance, overloaded, etc.), you're stuck. You've given the OpenVPN client no other option than to retry endlessly (or whatever you've specified for max retries). IMO, you should *always* provide at least three (3) servers (in the form of additional remote directives) to any OpenVPN client to minimize the risk of having the OpenVPN client fail to get connected.


It's either that, or else the script should not just blindly assume the OpenVPN client actually gets connected. Instead, it should follow-up the (re)start w/ a check that the connection completed. Admittedly OpenVPN doesn't make that easy, and why I prefer to provide multiple servers (thus let OpenVPN itself manage that process). But I assume that would undermine the usefulness of the vpnmgr (i.e., that script is purposely showing preference to a single server). If so, that may be its fatal flaw.
FWIW i don't see this issue on 3 routers I run vpnmgr on, but all 3 are connecting to UK servers. perhaps NordVPN's servers in other regions aren't reliable for some reason?
 
FWIW i don't see this issue on 3 routers I run vpnmgr on, but all 3 are connecting to UK servers. perhaps NordVPN's servers in other regions aren't reliable for some reason?

VPN servers are *never* going to be as reliable as your ISP connection. There's always the risk of servers being unavailable, if only for maintenance purposes. Of course, the less reputable providers are equally less reliable, but probably for other reasons (overloaded servers, changing or offlining server locations when the economics warrant it, etc.). But regardless of VPN provider, it's a risk to assume the reliability of VPN connections matches that of your ISP. What the syslog from the OP is showing is exactly what I'd expect when a given server just isn't available. I don't have any reason to suspect it's something else, like a bug.
 
Admittedly, I'm NOT familiar w/ the vpnmgr script. I've only given it a cursory glance. And it seems it relies on the NordVPN API to choose the server. But I don't know if that necessarily means it is guaranteed to be available. Like I've told ppl when using OpenVPN normally via the GUI, I consider it a mistake to specify only *one* server in your OpenVPN client configuration for this very reason. If by chance that server isn't available (down for maintenance, overloaded, etc.), you're stuck. You've given the OpenVPN client no other option than to retry endlessly (or whatever you've specified for max retries). IMO, you should *always* provide at least three (3) servers (in the form of additional remote directives) to any OpenVPN client to minimize the risk of having the OpenVPN client fail to get connected.

NordVPN doesn't make it easy to find steady, stable vpn server hostnames so you can specify them in a vpn config, and just call them with a remote-random. That would have been preferable, but I found that they change, disappear, and new ones are put in their place, all with a random 4-digit naming convention depending on which city you want to connect to. I have 5 servers specified, each in a different city. Unfortunately, vpnmgr can only do so much, which is query the NordVPN API and put the recommended server names in each of my configs... then openvpn takes over to make that connection. Invariably, one of these servers does not answer, or isn't there. But there's no way to get out of this loop until you kill it yourself, unless there's an easier way for me to run some kind of cronjob script that can determine if a successful vpn is running or not on one of my 5 clients, and mind you, that 4 of them won't be connected, and the 5th random one will be attempting a connection/or is connected.

FWIW i don't see this issue on 3 routers I run vpnmgr on, but all 3 are connecting to UK servers. perhaps NordVPN's servers in other regions aren't reliable for some reason?

As you know, I have 5 different locations set through vpnmgr... I thought perhaps a certain city was causing issues, so I have been shifting those around as well in order to find something that's working... like, incase "Chicago" just has a bunch of invalid servers or other kinds of issues... but that doesn't seem to do the trick. I wish there was a way to validate whether the server name is legit, or is answering before openvpn attempts a connection. :(
 
As you know, I have 5 different locations set through vpnmgr... I thought perhaps a certain city was causing issues, so I have been shifting those around as well in order to find something that's working... like, incase "Chicago" just has a bunch of invalid servers or other kinds of issues... but that doesn't seem to do the trick. I wish there was a way to validate whether the server name is legit, or is answering before openvpn attempts a connection. :(
i'll put something in the next version that attempts a ping across the tunnel or something
 
As @Jack Yaz suggests, it is possible to ping the tunnel's network interface specifically to see if the connection has been made and is working.

Code:
ping -I tun11 8.8.8.8

So your randomizer script could be modified to make this check, and if it fails after several tries within a given time limit, perhaps re-enter the script and try again.
 
As @Jack Yaz suggests, it is possible to ping the tunnel's network interface specifically to see if the connection has been made and is working.

Code:
ping -I tun11 8.8.8.8

So your randomizer script could be modified to make this check, and if it fails after several tries within a given time limit, perhaps re-enter the script and try again.
I've already started implementing something to this effect in vpnmgr https://github.com/jackyaz/vpnmgr/commits/develop
 
**EDIT from the OP. I believe the issues regarding the "endless unable to connect loop" was an issue on my end, stemming from a rogue openvpnclient1.postconf file sitting in my scripts folder, referencing lots of remote random expressvpn servers on port 1195. Since removing that file, vpnmgr has been working flawlessly. Thanks to @Jack Yaz for his support!
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top