Failover between OpenVPN Clients?

[Viktor Jaep]

Hi there... my VPN provider at times will do maintenance at my preferred exit locations, even sometimes completely eliminating these locations without warning, causing my connection to go down. I must go through and manually enable another VPN Client that I had preconfigured for events like this... and after going through this a couple of times now, was hoping to automate this a bit more?

I was wondering if there is any technique out there for possibility configuring the router to failover to another VPN Client slot should one go down, or if a public IP is not obtained within a certain timeout?

Or perhaps, is there a way to rotate between VPN Client slots on a periodic basis, and if one does not pick up/connect, move on to one that does connect?

Thank you for your advice!

 

[Martineau]

Hi there... my VPN provider at times will do maintenance at my preferred exit locations, even sometimes completely eliminating these locations without warning, causing my connection to go down. I must go through and manually enable another VPN Client that I had preconfigured for events like this... and after going through this a couple of times now, was hoping to automate this a bit more?

I was wondering if there is any technique out there for possibility configuring the router to failover to another VPN Client slot should one go down, or if a public IP is not obtained within a certain timeout?

Or perhaps, is there a way to rotate between VPN Client slots on a periodic basis, and if one does not pick up/connect, move on to one that does connect?

Thank you for your advice!

Does this VPN Failover script help ?

 

[Viktor Jaep]

Does this VPN Failover script help ?

I was just going to edit my post to let people know I just found this... let me pour over this, and see if I can make this work. I'm not a huge scripting guy, but I will attempt it! Thank you.

 

[Viktor Jaep]

Does this VPN Failover script help ?

Martineau... I think this will work beautifully! Thanks much for putting this together!

As I was playing with this, I had a question... Thanks in advance:

1.) I have 3 slots configured, and have it monitoring my primary connection in slot 3, so I used the command: VPN_Failover 3 ignore=4,5
2.) WhileI was testing, I used the command, VPN_Failover 2 ignore=4,5, and it started up my 2nd slot... at which point both slots 2 and 3 were connected... both given public IPs.

In a case like this where 2 or perhaps 3 slots are legitimately started up and connected, will this cause any routing issues for outgoing traffic? Or do these connections need to be manually shut down? How does it know which connection to use to route outgoing traffic if there are 3 slots connected? I don't believe the script will shut down the unused slots, correct?

Thank you!

 

[Martineau]

1.) I have 3 slots configured, and have it monitoring my primary connection in slot 3, so I used the command: VPN_Failover 3 ignore=4,5
2.) While I was testing, I used the command, VPN_Failover 2 ignore=4,5, and it started up my 2nd slot... at which point both slots 2 and 3 were connected... both given public IPs.
In a case like this where 2 or perhaps 3 slots are legitimately started up and connected, will this cause any routing issues for outgoing traffic?
How does it know which connection to use to route outgoing traffic if there are 3 slots connected?

The RPDB rules dictate which routing table is used, with VPN Client 1 having the highest priority, and VPN Client 5 the lowest priority.

So if an IP address (or overlapping CIDR) is defined in multiple VPN clients that are concurrently ACTIVE, then Selective routing may not work as desired.

P.S. The script is capable of terminating a monitored VPN Client, i.e. if the throughput performance falls below the minimum allowed, then it will stop the slow VPN Client and start the next appropriate VPN Client defined.

The original idea behind VPN Failover was based on the premise that you only need one VPN client ACTIVE at any one time (although as you have found, you can have several instances of VPN Failover running, with each monitoring its own VPN Client.)

So there are two options

1. Monitor VPN Client 1, and if it goes DOWN, switch to the next available configured VPN Client in a round-robin fashion.

2. Monitor VPN Client 1, and if it goes DOWN, restart VPN Client 1 using either the same exit point server, or automatically select from a list of exit points you specify.

If you don't need the additional features provided by my script, you could configure resiliency for a failed VPN Client exit server by simply specifying in the GUI a list of exit points:

e.g. Define two backup/alternative VPN exit points using different ports/protocols.

remote-random
remote server1.loc 553 udp
remote server2.loc 443 tcp-client

Perhaps the above will satisfy your objective without having to install my script?

 

[Viktor Jaep]

1. Monitor VPN Client 1, and if it goes DOWN, switch to the next available configured VPN Client in a round-robin fashion.

2. Monitor VPN Client 1, and if it goes DOWN, restart VPN Client 1 using either the same exit point server, or automatically select from a list of exit points you specify.

?

Thanks very much for the further detailed information on how this works, Martineau! I'm going to stick with option #1, and think this will work great. I can't wait to see it in action. I really appreciate you making this available to the community!

 

[Viktor Jaep]

Perhaps the above will satisfy your objective without having to install my script?

Hi Martineau... I was wondering if I could seek your advice again, please?

I seemed to have great success with your script on 384.15... but going to 384.16, I seem to be running up against issues. Throughout the day, when the script detects the connection going down, it has issues closing down the previous connection before moving to the next VPN slot and will end up with multiple VPN connections going at once, and all clients unable to get to the internet probably due to some routing confusion. Here's an example where it didn't shut down VPN Client 5 ... and Client 1 had been running the entire time.

...
VPN Client 5 connection status OK
Will check VPN Client 5 connection status again in 00:00:30 .....@15:11:28

15:11:28 v1.23 VPN Client Monitor: Checking VPN Client 5 connection status....
Switching VPN Client 5 to VPN Client 1 (Reason: VPN Client 5 STATE:0;Disconnected)
Waiting 60 secs for VPN Client 1 (ExpressVPN Tampa) to connect.....

VPN Client 1 (ExpressVPN Tampa) connect'd in 0 secs
Will check VPN Client 1 connection status again in 00:00:30 .....@15:12:12

Do you have any ideas?

Thank you!

 

[Martineau]

I seemed to have great success with your script on 384.15... but going to 384.16, I seem to be running up against issues

Do you have any ideas?

I can't write scripts fit for purpose?

Strange that you suspect v384.16 has altered the way VPN Clients execute/interact with my monitoring v1.23 script, but without seeing the output from 'VPN_Failover status' etc. it is extremely difficult to provide an explanation.

However I recall I did tinker with 'VPN_Failover.sh' several months ago....but never published it.

You can try v1.24 from my GitHub 'dev' branch to see if it works any better...

curl --retry 3 "https://raw.githubusercontent.com/MartineauUK/VPN-Failover/dev/VPN_Failover.sh" -o "/jffs/scripts/VPN_Failover.sh" && chmod 755 "/jffs/scripts/VPN_Failover.sh"

​

 

[Viktor Jaep]

I can't write scripts fit for purpose? ​

I love your script!! It was exactly what I was looking for, and worked great!

Strange that you suspect v384.16 has altered the way VPN Clients execute/interact with my monitoring v1.23 script, but without seeing the output from 'VPN_Failover status' etc. it is extremely difficult to provide an explanation.

That is literally the only change that was made... upgrading from .15 to .16. Followed by days of instability from the VPN side. My family was about to kill me, and have had to turn it off for a while to help them cool down a bit.

However I recall I did tinker with 'VPN_Failover.sh' several months ago....but never published it.

You can try v1.24 from my GitHub 'dev' branch to see if it works any better...

I will certainly give this a try, and will report back with the results of 'VPN_Failover status" if it continues running into issues. Thanks again for your advice!
​

 

[Viktor Jaep]

You can try v1.24 from my GitHub 'dev' branch to see if it works any better...

curl --retry 3 "https://raw.githubusercontent.com/MartineauUK/VPN-Failover/dev/VPN_Failover.sh" -o "/jffs/scripts/VPN_Failover.sh" && chmod 755 "/jffs/scripts/VPN_Failover.sh"

​

Hi Martineau... I'm running into an issue getting the script started saying that it's already running, and not sure how to get beyond this?

vjaep@RT-AC3100-5FD8:/jffs/scripts# ./VPN_Failover.sh 1

(VPN_Failover.sh): 4308 v1.24 Started..... [1]
        ***ERROR: VPN Client 1 Failover monitor already running!
                 4308 vjaep 1476 S {VPN_Failover.sh} /bin/sh ./VPN_Failover.sh 1

vjaep@RT-AC3100-5FD8:/jffs/scripts#

Not sure what else to do... this is what I tried:

1.) Renamed 2 suspicious VPN-related files under /jffs/scripts called:

• temp-openvpn-event
• temp-vpnclient1-route-up

2.) Renamed 1 file under /tmp called:

• VPN_Failover.sh-flock

3.) Rebooted, but this tmp file above seems to have come back.

Could you please let me know what else I could try? BTW... here's the status:

vjaep@RT-AC3100-5FD8:/jffs/scripts# ./VPN_Failover.sh status

(VPN_Failover.sh): 10361 v1.24 Started..... [status]
        Active VPN Failover monitor processes

vjaep@RT-AC3100-5FD8:/jffs/scripts#

Thank you!

EDIT: So I figured it out. It has to do with v1.24. I loaded v1.23 back on, and it seems to be working fine?

 

[Martineau]

I'm running into an issue getting the script started saying that it's already running, and not sure how to get beyond this?

EDIT: So I figured it out. It has to do with v1.24. I loaded v1.23 back on, and it seems to be working fine?

vjaep@RT-AC3100-5FD8:/jffs/scripts# ./VPN_Failover.sh 1

(VPN_Failover.sh): 4308 v1.24 Started..... [1]
        ***ERROR: VPN Client 1 Failover monitor already running!
                 4308 vjaep 1476 S {VPN_Failover.sh} /bin/sh ./VPN_Failover.sh 1

vjaep@RT-AC3100-5FD8:/jffs/scripts#

Not sure what else to do... this is what I tried:

1.) Renamed 2 suspicious VPN-related files under /jffs/scripts called:

• temp-openvpn-event
• temp-vpnclient1-route-up

2.) Renamed 1 file under /tmp called:

• VPN_Failover.sh-flock

3.) Rebooted, but this tmp file above seems to have come back.

Could you please let me know what else I could try? BTW... here's the status:

vjaep@RT-AC3100-5FD8:/jffs/scripts# ./VPN_Failover.sh status

(VPN_Failover.sh): 10361 v1.24 Started..... [status]
        Active VPN Failover monitor processes

vjaep@RT-AC3100-5FD8:/jffs/scripts#

Thank you!

Apologies

I'll take a another look at v1.24 but I'm sure it was for an edge-case I had previously experienced - hence didn't think it warranted a public release.

Regrettably, as you have found, during development I may have come to the conclusion that the edge-case was probably truly obscure, and abandoned the hacked v1.24 script but unfortunately dumped it on you as-is.

 

[Viktor Jaep]

Apologies

Hi Martineau... it's not a problem. I really appreciate your help and coming up with this script. I have spent some time diving into my VPN woes a bit more, and think I've made some headway on getting things stabilized... Using ExpressVPN, this thread was extremely helpful: https://www.snbforums.com/threads/expressvpn-merlin-384-15.61656/#post-548393

Here's what I did:

Compression: Disabled
Verify Server Certificate Name: No​

And added/changed several items to my config that I seemed to be missing:

fast-io
remote-random
pull
tls-client
verify-x509-name Server name-prefix
remote-cert-tls server
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1450
keysize 256
sndbuf 524288
rcvbuf 524288
comp-lzo no
push "comp-lzo no"
auth-nocache​

The v1.23 Failover script has been working perfect ever since...

 

[Martineau]

The v1.23 Failover script has been working perfect ever since...

Glad you got it sorted.

P.S. I think I fixed the brain-dead v1.24 on GitHub 'dev' branch a couple of weeks ago, but if v1.23 works, then "why fix it if it ain't broke...."

 

[Viktor Jaep]

P.S. I think I fixed the brain-dead v1.24 on GitHub 'dev' branch a couple of weeks ago, but if v1.23 works, then "why fix it if it ain't broke...."

I would be happy to beta it for you... loaded v1.24 and seems to be working great. I'll check in if I see anything strange! Thank you!

 

[Viktor Jaep]

Glad you got it sorted

Hi @Martineau... it seems that v1.24 is giving me something unexpected when it rolls from one client to another? It seems to leave an orphaned PID file? Yesterday I had 2 of them... but as expected, after a reboot, they went away... but this is as of this morning. I don't believe v1.23 did that, but I could be mistaken? Are there any bad side-effects when it does roll back onto vpnclient1 in the future with an existing PID file?

vjaep@RT-AC3100-5FD8:/jffs/scripts# ./VPN_Failover.sh status

(VPN_Failover.sh): 11232 v1.24 Started..... [status]

        Active VPN Failover monitor processes

        ***ERROR Orphaned PID file '/tmp/vpnclient1-VPNFailover'
10898 vjaep 1492 S {VPN_Failover.sh} /bin/sh ./VPN_Failover.sh 2
 6 May 3 09:20 /tmp/vpnclient2-VPNFailover Status/PID=10898

 

[Martineau]

Hi @Martineau... it seems that v1.24 is giving me something unexpected when it rolls from one client to another? It seems to leave an orphaned PID file? Yesterday I had 2 of them... but as expected, after a reboot, they went away... but this is as of this morning. I don't believe v1.23 did that, but I could be mistaken? Are there any bad side-effects when it does roll back onto vpnclient1 in the future with an existing PID file?

vjaep@RT-AC3100-5FD8:/jffs/scripts# ./VPN_Failover.sh status

(VPN_Failover.sh): 11232 v1.24 Started..... [status]

        Active VPN Failover monitor processes

        ***ERROR Orphaned PID file '/tmp/vpnclient1-VPNFailover'
10898 vjaep 1492 S {VPN_Failover.sh} /bin/sh ./VPN_Failover.sh 2
 6 May 3 09:20 /tmp/vpnclient2-VPNFailover Status/PID=10898

Ok, I think I'll dump v1.24
Apologies for the inconvenience.

 

[Viktor Jaep]

Ok, I think I'll dump v1.24
Apologies for the inconvenience.

Not a prob... I'll revert back to v1.23. Thanks for letting me test!

 

[Viktor Jaep]

Hi @Martineau !

I continue to exhibit strange problems on occasion, and would truly appreciate your advice on how to diagnose and possibly resolve this issue? I am using your script successfully, and it certainly works as advertised to move from one VPN profile to another should the tunnel go down. I certainly value your knowledge on this subject greatly!

Problem:
1.) In certain cases, when the script moves to the next VPN profile, it seems as if everything connects successfully (ie. I receive a public IP, and you can see "some" traffic being transferred, but it is not as much as what you would normally see, and can tell immediately that something is not right. In cases like these, the VPN_Failover script continues to report that the tunnel is up, however none of the clients can browse, and the internet is down only for the VPN clients. Clients that are not forced through the tunnel can get to the internet just fine.

So even though none of the clients can browse the internet, the script will log this just as normal:

May 23 08:25:12 (VPN_Failover.sh): 17559 VPN Client Monitor: Checking VPN Client 4 connection status....
May 23 08:25:12 (VPN_Failover.sh): 17559 VPN Client Monitor: VPN Client 4 status OK
May 23 08:25:12 (VPN_Failover.sh): 17559 Will check VPN Client 4 connection status again in 00:00:30 .....@08:25:42

2.) If I stop this particular tunnel manually (after killing the script), and restart the tunnel manually, then it will be fine... clients can again browse the internet, etc.

I have included some more information from the logs... during this event, my WAN connection went down as it was trying to reconnect to the next VPN profile, but in this case when it successfully reconnected, the VPN clients could not browse the internet:

May 23 08:17:56 (VPN_Failover.sh): 17559 **VPN Client Monitor: Switching VPN Client 2 to VPN Client 4 (Reason: VPN Client 3 STATE=1;Connecting)
May 23 08:17:56 (VPN_Failover.sh): 17559 **VPN Client Monitor: Terminating VPN Client 3
May 23 08:17:56 rc_service: service 4121:notify_rc stop_vpnclient3
May 23 08:17:56 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient3)
May 23 08:17:56 (VPN_Failover.sh): 17559 Waiting for VPN Client 3 (ExpressVPN Dallas) to disconnect.....
May 23 08:18:08 kernel: EMF_ERROR: Interface tun13 doesn't exist
May 23 08:18:08 kernel: EMF_ERROR: Interface tap13 doesn't exist
May 23 08:18:10 (VPN_Failover.sh): 17559 VPN Client 3 (ExpressVPN Dallas) disconnect'd in 12 secs
May 23 08:18:10 rc_service: service 4269:notify_rc start_vpnclient4
May 23 08:18:10 custom_script: Running /jffs/scripts/service-event (args: start vpnclient4)
May 23 08:18:10 (VPN_Failover.sh): 17559 Waiting for VPN Client 4 (ExpressVPN Washington DC) to connect.....
May 23 08:18:11 ovpn-client4[4325]: WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
May 23 08:18:11 ovpn-client4[4325]: OpenVPN 2.4.9 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 25 2020
May 23 08:18:11 ovpn-client4[4325]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.08
May 23 08:18:11 ovpn-client4[4326]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 23 08:18:11 ovpn-client4[4326]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
May 23 08:18:11 ovpn-client4[4326]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
May 23 08:18:27 ovpn-client4[4326]: RESOLVE: Cannot resolve host address: usa-washingtondc-ca-version-2.expressnetw.com:1195 (Name or service not known)
May 23 08:18:33 ovpn-client4[4326]: RESOLVE: Cannot resolve host address: usa-washingtondc-ca-version-2.expressnetw.com:1195 (Name or service not known)
May 23 08:18:33 ovpn-client4[4326]: Could not determine IPv4/IPv6 protocol
May 23 08:18:33 ovpn-client4[4326]: SIGUSR1[soft,init_instance] received, process restarting
May 23 08:18:33 ovpn-client4[4326]: Restart pause, 5 second(s)
May 23 08:18:38 ovpn-client4[4326]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 23 08:18:44 ovpn-client4[4326]: RESOLVE: Cannot resolve host address: usa-washingtondc-ca-version-2.expressnetw.com:1195 (Name or service not known)
May 23 08:18:50 ovpn-client4[4326]: RESOLVE: Cannot resolve host address: usa-washingtondc-ca-version-2.expressnetw.com:1195 (Name or service not known)
May 23 08:18:50 ovpn-client4[4326]: Could not determine IPv4/IPv6 protocol
May 23 08:18:50 ovpn-client4[4326]: SIGUSR1[soft,init_instance] received, process restarting
May 23 08:18:50 ovpn-client4[4326]: Restart pause, 5 second(s)
May 23 08:18:55 ovpn-client4[4326]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 23 08:19:01 ovpn-client4[4326]: RESOLVE: Cannot resolve host address: usa-washingtondc-ca-version-2.expressnetw.com:1195 (Name or service not known)
May 23 08:19:01 ovpn-client4[4326]: Socket Buffers: R=[122880->245760] S=[122880->245760]
May 23 08:19:01 ovpn-client4[4326]: UDP link local: (not bound)
May 23 08:19:01 ovpn-client4[4326]: UDP link remote: [AF_INET]104.238.32.27:1195
May 23 08:19:01 ovpn-client4[4326]: TLS: Initial packet from [AF_INET]104.238.32.27:1195, sid=d5d45438 aa1fb96f
May 23 08:19:02 ovpn-client4[4326]: VERIFY OK: depth=1, C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=ExpressVPN CA, emailAddress=support@expressvpn.com
May 23 08:19:02 ovpn-client4[4326]: VERIFY KU OK
May 23 08:19:02 ovpn-client4[4326]: Validating certificate extended key usage
May 23 08:19:02 ovpn-client4[4326]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
May 23 08:19:02 ovpn-client4[4326]: VERIFY EKU OK
May 23 08:19:02 ovpn-client4[4326]: VERIFY X509NAME OK: C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=Server-6044-0a, emailAddress=support@expressvpn.com
May 23 08:19:02 ovpn-client4[4326]: VERIFY OK: depth=0, C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=Server-6044-0a, emailAddress=support@expressvpn.com
May 23 08:19:02 ovpn-client4[4326]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
May 23 08:19:02 ovpn-client4[4326]: [Server-6044-0a] Peer Connection Initiated with [AF_INET]104.238.32.27:1195
May 23 08:19:02 WAN_Connection: WAN was restored.
May 23 08:19:02 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 23 08:19:03 ovpn-client4[4326]: SENT CONTROL [Server-6044-0a]: 'PUSH_REQUEST' (status=1)
May 23 08:19:03 ovpn-client4[4326]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.101.0.1,comp-lzo no,route 10.101.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.101.0.130 10.101.0.129,peer-id 31,cipher AES-256-GCM'
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: timers and/or timeouts modified
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: compression parms modified
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: --ifconfig/up options modified
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: route options modified
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: peer-id set
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: adjusting link_mtu to 1629
May 23 08:19:03 ovpn-client4[4326]: OPTIONS IMPORT: data channel crypto options modified
May 23 08:19:03 ovpn-client4[4326]: Data Channel: using negotiated cipher 'AES-256-GCM'
May 23 08:19:03 ovpn-client4[4326]: NCP: overriding user-set keysize with default
May 23 08:19:03 ovpn-client4[4326]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
May 23 08:19:03 ovpn-client4[4326]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
May 23 08:19:03 ovpn-client4[4326]: TUN/TAP device tun14 opened
May 23 08:19:03 ovpn-client4[4326]: TUN/TAP TX queue length set to 1000
May 23 08:19:03 ovpn-client4[4326]: /sbin/ifconfig tun14 10.101.0.130 pointopoint 10.101.0.129 mtu 1500
May 23 08:19:03 ovpn-client4[4326]: updown.sh tun14 1500 1557 10.101.0.130 10.101.0.129 init
May 23 08:19:03 openvpn-updown: Forcing 192.168.1.0/24 to use DNS server 10.101.0.1
May 23 08:19:03 openvpn-updown: Excluding 192.168.1.84 from forced DNS routing
May 23 08:19:03 openvpn-updown: Excluding 192.168.1.74 from forced DNS routing
May 23 08:19:04 openvpn-updown: Excluding 192.168.1.90 from forced DNS routing
May 23 08:19:04 rc_service: service 4735:notify_rc updateresolv
May 23 08:19:04 custom_script: Running /jffs/scripts/service-event (args:  updateresolv)
May 23 08:19:06 openvpn-routing: Configuring policy rules for client 4
May 23 08:19:07 ovpn-client4[4326]: Initialization Sequence Completed
May 23 08:19:07 (VPN_Failover.sh): 17559 VPN Client 4 (ExpressVPN Washington DC) connect'd in 55 secs
May 23 08:19:07 (VPN_Failover.sh): 17559 Will check VPN Client 4 connection status again in 00:00:30 .....@08:19:37
May 23 08:19:37 (VPN_Failover.sh): 17559 VPN Client Monitor: Checking VPN Client 4 connection status....
May 23 08:19:38 (VPN_Failover.sh): 17559 VPN Client Monitor: VPN Client 4 status OK

3.) Is there a possibility that the router was not able to successfully recover from it's last VPN profile, so that routing information wasn't able to populate correctly after the next VPN profile establishes itself? Should I be using some different arguments in the VPN_Failover.sh script commandline to try to test for something else that might give an indication that the internet is not resolvable on this particular tunnel?

Thank you!