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 ...