What's new

vpnmgr vpnmgr - Manage and update VPN Client configurations for NordVPN and PIA

  • 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!

Which VPN provider do you use?


  • Total voters
    315
Reduce your line length in the options with the line that starts with mssfix. (I would remove to test first).
Should have noted this in the original post, but I deleted the section that was inserted into the configuration that started with msfix, but it seems like it comes back.
 
Reset the VPN client to defaults, reboot the router, ensure it has been removed, then add it again.
 
vpnmgr needs updating as 386.3 stores custom configuration differently to previous firmware versions. it's on my to-do
You're a busy man! Long overdue but donation sent your way.
 
vpnmgr needs updating as 386.3 stores custom configuration differently to previous firmware versions. it's on my to-do
This brings to mind something I've been wondering about. Your configuration options are slightly different than what NordVPN has listed on their How-To. Was there something you discovered along the way that made you decide to add the additional options? I'm hoping to get a better understanding of what it all means.

Code:
remote-cert-tls server
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping-timer-rem
reneg-sec 0

#log /tmp/vpn.log

Code:
remote-random
resolv-retry infinite
remote-cert-tls server
ping 15
ping-restart 0
ping-timer-rem
persist-key
persist-tun
reneg-sec 0
fast-io
disable-occ
mute-replay-warnings
auth-nocache
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
pull-filter ignore "auth-token"
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
 
This brings to mind something I've been wondering about. Your configuration options are slightly different than what NordVPN has listed on their How-To. Was there something you discovered along the way that made you decide to add the additional options? I'm hoping to get a better understanding of what it all means.

Code:
remote-cert-tls server
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping-timer-rem
reneg-sec 0

#log /tmp/vpn.log

Code:
remote-random
resolv-retry infinite
remote-cert-tls server
ping 15
ping-restart 0
ping-timer-rem
persist-key
persist-tun
reneg-sec 0
fast-io
disable-occ
mute-replay-warnings
auth-nocache
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
pull-filter ignore "auth-token"
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
yes, i found my settings gave me better performance. i'm going to make the custom settings optional in the next version so users can tweak things if they want to
 
Not sure how you like to receive feature requests, but it would be great to have the option to have the VPN monitored for connectivity and reconnect any time the VPN connection drops but the WAN connection is still active. Perhaps by having a VPN fallover option. I've had issues in the past where the VPN client drops and my IoT devices are no longer accessible. Currently workaround this by having the VPN connection reconnect every 30 minutes. This functionality would preserve VPN killswitch behavior while not locking out devices connected to that VPN from connectivity.
 
v2.3.1 is now available
Changelog:

  • CHANGED: service-event hook is more selective when it calls vpnmgr
 
Not sure how you like to receive feature requests, but it would be great to have the option to have the VPN monitored for connectivity and reconnect any time the VPN connection drops but the WAN connection is still active. Perhaps by having a VPN fallover option. I've had issues in the past where the VPN client drops and my IoT devices are no longer accessible. Currently workaround this by having the VPN connection reconnect every 30 minutes. This functionality would preserve VPN killswitch behavior while not locking out devices connected to that VPN from connectivity.
this is on the "to do at some point"
 
this is on the "to do at some point"

@Jack Yaz

I think some variation of this would be a very worthwhile improvement if you were so inclined, but a couple of additional thoughts do occur ... and thank you in advance for all you do with your Add-Ons, and reading and considering my rubbish!

Background:-

I've tinkered with using vpnmgr, but currently have it turned off (not managed) for my one NordVPN client, as I was finding it counter-productive in my situation at least. I found that the "Scheduled Update/Reload" was picking servers that, whilst they may well have had a lower "load", were often markedly slower in throughput. This seemed to me to defeat the whole purpose somewhat. I don't know if this is confined to the Sydney Australia servers I use. I found that I was better off testing the various servers and by trial and error compiling my own mini-list of "preferred" servers that had better throughput and relatively low load. I then "manually" stick to this list, and if a particular one goes down for some reason I then switch to the next most favoured one ... and so on. Pretty rare that I've had to do it.

Ideally:-

As per @abracadabra11's suggestions Vpnmgr would monitor the OVPN connection and restart it in the first instance and then fail-over if that didn't succeed. Number of retries, time gap between them etc before going on to another server configurable by user? I'd also like a user-configurable list of 1st, 2nd, 3rd, (4th, 5th ?) preference servers that vpnmgr would try if it needs to failover, rather than just picking another one based on load as Scheduled Update/Reload does now, for the reasons I've stated above.

If I May Be So Impertinent (As Usual):-

Bonus points would be awarded if there was some automated "intelligence" that went along with this. Maybe vpnmgr could use a "spare" OVPN client (suspect not many people use all 5) to be the "test circuit" and regularly try and establish which particular servers in the designated city/country have both low loads and good throughput and are the "sweet spot". Some thought would need to be put into what constituted "best" in terms of when the testing was done (peak/off-peak for particular location etc) and what the weighting was between load versus throughput etc. Those "top" 3-5 results would then constitute what got used in the event of a need to failover. And a "failover" in terms of vpnmgr could really be just like a "demand-triggered" variant of your current "Schedued Update/Reload" but constrained to the "Top List" only, ie not actually taking up a separate OVPN Client and switching to it as some of the other scripts I've seen do. Not sure how that old approach would go with VPN Director anyway?

Additionally:-

I only have one device going through the VPN, a Synology NAS via a single IP routed to OVPN1 in VPN Director. I seem to randomly get the situation after a router reboot (maybe 1 in 6?) where the VPN has ostensibly established/connected and shows like it is everywhere in the Asus interface, but at the Synology end no data is flowing and it can't connect. A manual restart of the VPN via scMerlin always instantly gets it going again. Nothing to do with your VPNmgr, pre-dates that, but it has persisted across many Merlin versions and happened again this morning for the 1st time after upgrading to 386.3 / VPN Director, so it's consistent. Not a biggie, just a minor glitch, but it would be nice if any re-jigging of vpnmgr had as a byproduct a "fix" for this little annoyance.

Apologies for the length of this missive - Sydney is back in full COVID Lockdown (since 26th June) with no end in sight and I obviously have far too much time on my hands ...

:)
 
Last edited:
Hi Jack,

Trying to install this script on AX11000 running 386.3 firmware and I get error when installing this script.
Capture.PNG


The vpnmgr page also doesn't load.
Capture2.PNG


What am I doing wrong? How can I fix this?
 
@Jack Yaz

I think some variation of this would be a very worthwhile improvement if you were so inclined, but a couple of additional thoughts do occur ... and thank you in advance for all you do with your Add-Ons, and reading and considering my rubbish!

Background:-

I've tinkered with using vpnmgr, but currently have it turned off (not managed) for my one NordVPN client, as I was finding it counter-productive in my situation at least. I found that the "Scheduled Update/Reload" was picking servers that, whilst they may well have had a lower "load", were often markedly slower in throughput. This seemed to me to defeat the whole purpose somewhat. I don't know if this is confined to the Sydney Australia servers I use. I found that I was better off testing the various servers and by trial and error compiling my own mini-list of "preferred" servers that had better throughput and relatively low load. I then "manually" stick to this list, and if a particular one goes down for some reason I then switch to the next most favoured one ... and so on. Pretty rare that I've had to do it.
not something i've seen on the UK servers, i'm always able to pull 200+ (router based speedtest)
Ideally:-

As per @abracadabra11's suggestions Vpnmgr would monitor the OVPN connection and restart it in the first instance and then fail-over if that didn't succeed. Number of retries, time gap between them etc before going on to another server configurable by user? I'd also like a user-configurable list of 1st, 2nd, 3rd, (4th, 5th ?) preference servers that vpnmgr would try if it needs to failover, rather than just picking another one based on load as Scheduled Update/Reload does now, for the reasons I've stated above.
I'll +1 the idea on the scrap of paper I use for things i'd like to add if I have time
Bonus points would be awarded if there was some automated "intelligence" that went along with this. Maybe vpnmgr could use a "spare" OVPN client (suspect not many people use all 5) to be the "test circuit" and regularly try and establish which particular servers in the designated city/country have both low loads and good throughput and are the "sweet spot". Some thought would need to be put into what constituted "best" in terms of when the testing was done (peak/off-peak for particular location etc) and what the weighting was between load versus throughput etc. Those "top" 3-5 results would then constitute what got used in the event of a need to failover. And a "failover" in terms of vpnmgr could really be just like a "demand-triggered" variant of your current "Schedued Update/Reload" but constrained to the "Top List" only, ie not actually taking up a separate OVPN Client and switching to it as some of the other scripts I've seen do. Not sure how that old approach would go with VPN Director anyway?
some sort of crossover with spdmerlin could be possible to run tests across servers. i think the problem when I thought about this before is parsing the server list is slow on the older routers as at the time there wasn't a way to use the API to do the heavy lifting, e.g. "give me the 5 best servers". i had to do a lookup for all servers (for a given region), then parse them on the router and sort by the load value. wasn't too bad on my AC86U, but the 68U just couldn't do it in a reasonable time
Additionally:-

I only have one device going through the VPN, a Synology NAS via a single IP routed to OVPN1 in VPN Director. I seem to randomly get the situation after a router reboot (maybe 1 in 6?) where the VPN has ostensibly established/connected and shows like it is everywhere in the Asus interface, but at the Synology end no data is flowing and it can't connect. A manual restart of the VPN via scMerlin always instantly gets it going again. Nothing to do with your VPNmgr, pre-dates that, but it has persisted across many Merlin versions and happened again this morning for the 1st time after upgrading to 386.3 / VPN Director, so it's consistent. Not a biggie, just a minor glitch, but it would be nice if any re-jigging of vpnmgr had as a byproduct a "fix" for this little annoyance.
i sometimes see this with NordVPN - applying a new server (option 4 now, I think?) kicks the VPN client over in the same way that scmerlin does. it'd be interesting if you can test ping via the tunnel on the router to see if the tunnel isn't actually up, or the client routing is failing
Code:
ping -I tun11 8.8.8.8
Apologies for the length of this missive - Sydney is back in full COVID Lockdown (since 26th June) with no end in sight and I obviously have far too much time on my hands ...

:)
 
not something i've seen on the UK servers, i'm always able to pull 200+ (router based speedtest)

@Jack Yaz

Quite repeatable for me here. My “preferred” server does around 220 to as high as 270 depending on time of day etc, hovering mostly around 230-240. I have a middle group that does 210-230 but never or very rarely goes higher. I then have a less desirable group that does 170-200 but mostly would never crack 200. So definite variations. Hard to be really scientific as too many variables change as you are testing, but patterns definitely emerge.

Thanks for your other thoughts, and I’ll definitely try and remember to do the ping test on the tunnel next time my NAS can’t connect after a reboot.
 
i sometimes see this with NordVPN - applying a new server (option 4 now, I think?) kicks the VPN client over in the same way that scmerlin does. it'd be interesting if you can test ping via the tunnel on the router to see if the tunnel isn't actually up, or the client routing is failing

@Jack Yaz just reporting back ...

Got one of my random VPN "failures" with my NAS failing to connect after a router reboot, so did your suggested "ping -I tun11 8.8.8.8" from the CLI of the router.

Code:
admin@AsusRouter:/tmp/home/root# ping -I tun11 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=121 time=9.749 ms
64 bytes from 8.8.8.8: seq=1 ttl=121 time=9.035 ms
64 bytes from 8.8.8.8: seq=2 ttl=121 time=12.085 ms
64 bytes from 8.8.8.8: seq=3 ttl=121 time=8.866 ms
64 bytes from 8.8.8.8: seq=4 ttl=121 time=10.977 ms
64 bytes from 8.8.8.8: seq=5 ttl=121 time=9.372 ms

So I take that to mean the Tunnel is Up, but for some reason my NAS can't connect?

I SSHed into the NAS and tried pinging 8.8.8.8 but no go. Also could not ping the Router at it's address 192.168.1.254.
I then manually restarted the NAS network interface with a "sudo /etc/rc.network restart" but still no go and still couldn't ping 8.8.8.8 or 192.168.1.254

I then restarted the VPN Client on the RT-AX86U and as per usual it all "automagically" came good ...

Not sure what is going on, but nothing to do with vpnmgr from what I can see so I'll leave you alone as this is now Way Off-Topic ...

:)
 
Hi Jack,

Trying to install this script on AX11000 running 386.3 firmware and I get error when installing this script.
View attachment 35479

The vpnmgr page also doesn't load.
View attachment 35480

What am I doing wrong? How can I fix this?
Can anyone guide me on how to fix this, please? I've had to reset the router and when I reinstall this script, I get the same issue- country data failed to download.

Can I download the country data file manually and copy it somehwere?

Any help is greatly apprecaited.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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