VPNMON VPNMON-R2 v2.52 -Mar 27, 2023- Monitor your VPN connection's Health (Thread locked/closed)

[Kal1975]

Happened again. Here is part of the VPNMON log from the start of the internet down, at about 10:29pm, to the end of the log:

Tue Jul 19 17:18:37 DST 2022 - VPNMON-R2 - API call made to update VPN city to Wandsor
Tue Jul 19 22:29:29 DST 2022 - VPNMON-R2 ----------> ERROR: VPN2 Ping/HTTP response failed
Tue Jul 19 22:30:11 DST 2022 - VPNMON-R2 ----------> ERROR: Connection failed - Executing VPN Reset
Tue Jul 19 22:30:11 DST 2022 - VPNMON-R2 - Executing VPN Reset
Tue Jul 19 22:30:25 DST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Tue Jul 19 22:30:39 DST 2022 - VPNMON-R2 - Randomly selected VPN1 Client ON
Tue Jul 19 22:30:41 DST 2022 - VPNMON-R2 - VPN Reset Finished
Tue Jul 19 22:30:44 DST 2022 - VPNMON-R2 - Resuming normal operations
Tue Jul 19 22:30:55 DST 2022 - VPNMON-R2 - API call made to update WAN0 city to Syndey

I was looking through the system log and it looks like the VPN connection is trying to restart many times. I had "Connection Retry attempts" set to 15. If VPNMON is in use, that really should be set to 1, since VPNMON is handling the retries.

I'll set all VPN slots to have a retry of 1 and see how it goes.

So, in general, the automatic starts should be set to no and the retry attempts should be set to 1. In the Custom Configuration section, my VPN provider has "resolv-retry infinte" specified. Not sure if that causes any issues. I'll post an update if/when my internet connection goes down again...probably sooner than later.

 

[Viktor Jaep]

Happened again. Here is part of the VPNMON log from the start of the internet down, at about 10:29pm, to the end of the log:



I was looking through the system log and it looks like the VPN connection is trying to restart many times. I had "Connection Retry attempts" set to 15. If VPNMON is in use, that really should be set to 1, since VPNMON is handling the retries.

I'll set all VPN slots to have a retry of 1 and see how it goes.

So, in general, the automatic starts should be set to no and the retry attempts should be set to 1. In the Custom Configuration section, my VPN provider has "resolv-retry infinte" specified. Not sure if that causes any issues. I'll post an update if/when my internet connection goes down again...probably sooner than later.

Hey @Kal1975... looking at your log, I don't see anything out of the ordinary. From the time that the vpnreset started (including killing all your connections), took about 50seconds. Looks very normal, and gets things re-established. Do you have anything concerning in your syslogs that I'm not seeing here?

Those are probably good settings to use... My custom config also contains the "resolv-retry infinite", but this doesn't have any effect on vpnmon from operating correctly.

 

[Viktor Jaep]

I'm throwing a major beta update v2.1b1 out there to play with for anyone who would like to! This one includes a big change to the setup/configuration, and brings it more in line with my efforts with RTRMON. It's a cleaner, menu-based setup that lets you pick and choose settings to modify, instead of having to run through (what seems like) a never-ending list of options. Hopefully this is beneficial. Just so @Stephen Harrington knows... I have done away with the "press enter for your own custom default values" in the interim... I thought it would be easy enough to see what you already had selected from the main setup UI itself... Please note, there are a few sections (like item 6) that have a few dependencies tied to them, so if you want to change a setting under item 6, you would need to answer all questions related to it, because it has outcomes on the functionality of the program. Give it a go, and let me know what you think?

Also... I added an extra round of VPN client kill commands when the WAN goes south to see if that helps benefit @Kal1975's situation in the thread above...

Captain's Change Log - Stardate v2.1b1
- ADDED: Completely reworked the setup/config menus to make the look/feel/act like RTRMON's. The hope was to simplify the process, allowing one to pick and choose settings to configure, instead of having to run down a long laundry list of configuration questions. I have done away with the loading of current config values as "defaults" when hitting the enter button, as it would be fairly easy to scroll up and see what value you had in place if need be. Enter on a blank line now assumes you want the system default.
- ADDED: An extra round of VPN client kill commands when the router detects WAN trouble, just to make sure it pre-emptively kills everything incase these VPN clients try to reconnect while the WAN is down.

Screenshot:

Install link:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.1b1.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

 

[Kal1975]

Very nice!

@Viktor Jaep OK...happened again. This time, something slightly different. Before, the router became unresponsive and the VPN client that was being selected/started just kept retrying endlessly to connect while the internet connection was down. Now, when the internet connection came back up, with VPNMON running, it seemed that either VPNMON did not recognize that the internet connection had come back up or did and selected another VPN client to start but did not recognize that it had started...or both.

This is from the VPNMON log:

Wed Jul 20 09:26:52 DST 2022 - VPNMON-R2 ----------> ERROR: Connection failed - Executing VPN Reset
Wed Jul 20 09:26:52 DST 2022 - VPNMON-R2 - Executing VPN Reset
Wed Jul 20 09:27:08 DST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Wed Jul 20 09:27:22 DST 2022 - VPNMON-R2 - Randomly selected VPN3 Client ON
Wed Jul 20 09:27:24 DST 2022 - VPNMON-R2 - VPN Reset Finished
Wed Jul 20 09:27:27 DST 2022 - VPNMON-R2 - Resuming normal operations
Wed Jul 20 09:27:28 DST 2022 - VPNMON-R2 - API call made to update WAN0 city to Wandsor
Wed Jul 20 09:27:41 DST 2022 - VPNMON-R2 ----------> ERROR: Connection failed - Executing VPN Reset
Wed Jul 20 09:27:41 DST 2022 - VPNMON-R2 - Executing VPN Reset
Wed Jul 20 09:27:56 DST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Wed Jul 20 09:28:09 DST 2022 - VPNMON-R2 - Randomly selected VPN2 Client ON
Wed Jul 20 09:28:11 DST 2022 - VPNMON-R2 - VPN Reset Finished
Wed Jul 20 09:28:14 DST 2022 - VPNMON-R2 - Resuming normal operations
Wed Jul 20 09:28:15 DST 2022 - VPNMON-R2 - API call made to update WAN0 city to Wandsor
Wed Jul 20 09:28:28 DST 2022 - VPNMON-R2 ----------> ERROR: Connection failed - Executing VPN Reset
Wed Jul 20 09:28:28 DST 2022 - VPNMON-R2 - Executing VPN Reset
Wed Jul 20 09:28:44 DST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Wed Jul 20 09:28:58 DST 2022 - VPNMON-R2 - Randomly selected VPN2 Client ON
Wed Jul 20 09:29:00 DST 2022 - VPNMON-R2 - VPN Reset Finished
Wed Jul 20 09:29:02 DST 2022 - VPNMON-R2 - Resuming normal operations
Wed Jul 20 09:29:03 DST 2022 - VPNMON-R2 - API call made to update WAN0 city to Wandsor
Wed Jul 20 09:29:17 DST 2022 - VPNMON-R2 ----------> ERROR: Connection failed - Executing VPN Reset
Wed Jul 20 09:29:17 DST 2022 - VPNMON-R2 - Executing VPN Reset
Wed Jul 20 09:29:31 DST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Wed Jul 20 09:29:45 DST 2022 - VPNMON-R2 - Randomly selected VPN3 Client ON
Wed Jul 20 09:29:47 DST 2022 - VPNMON-R2 - VPN Reset Finished
Wed Jul 20 09:29:50 DST 2022 - VPNMON-R2 - Resuming normal operations
Wed Jul 20 09:29:51 DST 2022 - VPNMON-R2 - API call made to update WAN0 city to Wandsor

and on and on...

In the VPNMON GUI, after the WAN check and then the selection, the GUI was redrawn but it did not show that a VPN client was active. It only showed the ping time in ms where all 5 slots were grey. It also did not recognize that the WAN connection was restored.

After stopping and restarting VPNMON it showed that the WAN connection was up and that the slot was active. One thing I noticed in the VPNMON interface before restarting it was that near the top beside VPN State, it showed that one of the VPN slots had a 1 status and not 0 or 2. After restarting VPNMON, one of the slots showed a 2.

The syslogs before were not useful since the VPN client was just trying to restart. This time, the General syslog is showing what it seems that VPNMON is doing...it shows the VPN client that was selected being started successfully, and then what looks like the VPNMON reset happening. Here's a portion of the log showing what's happening. This keeps repeating:

Spoiler: Portion of General syslog

Jul 20 09:26:45 RT-AC3100-9488 (ChkWAN.sh): 20650 Monitoring connection OK.....(Successful ping to '9.9.9.9'). Will check again in 120 secs
Jul 20 09:26:52 RT-AC3100-9488 rc_service: service 9056:notify_rc stop_vpnclient1
Jul 20 09:26:52 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)
Jul 20 09:26:53 RT-AC3100-9488 ovpn-client1[7926]: event_wait : Interrupted system call (code=4)
Jul 20 09:26:53 RT-AC3100-9488 ovpn-client1[7926]: SIGTERM received, sending exit notification to peer
Jul 20 09:26:53 RT-AC3100-9488 rc_service: service 9057:notify_rc stop_vpnclient2
Jul 20 09:26:53 RT-AC3100-9488 rc_service: waitting "stop_vpnclient1" via ...
Jul 20 09:26:58 RT-AC3100-9488 ovpn-client1[7926]: ovpn-route-pre-down tun11 1500 1552 x.x.x.x 255.255.254.0 init
Jul 20 09:26:58 RT-AC3100-9488 ovpn-client1[7926]: Closing TUN/TAP interface
Jul 20 09:26:58 RT-AC3100-9488 ovpn-client1[7926]: /usr/sbin/ip addr del dev tun11 x.x.x.x/23
Jul 20 09:26:59 RT-AC3100-9488 ovpn-client1[7926]: ovpn-down 1 client tun11 1500 1552 x.x.x.x 255.255.254.0 init
Jul 20 09:26:59 RT-AC3100-9488 openvpn-routing: Configured killswitch on VPN client 1
Jul 20 09:26:59 RT-AC3100-9488 ovpn-client1[7926]: SIGTERM[soft,exit-with-notification] received, process exiting
Jul 20 09:26:59 RT-AC3100-9488 openvpn-routing: Clearing routing table for VPN client 1
... (interface doesn't exist)
Jul 20 09:27:00 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient2)
...
Jul 20 09:27:02 RT-AC3100-9488 rc_service: service 9304:notify_rc stop_vpnclient3
Jul 20 09:27:02 RT-AC3100-9488 rc_service: waitting "stop_vpnclient2" via ...
... (interface doesn't exist)
Jul 20 09:27:03 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient3)
Jul 20 09:27:04 RT-AC3100-9488 rc_service: service 9626:notify_rc stop_vpnclient4
Jul 20 09:27:04 RT-AC3100-9488 rc_service: waitting "stop_vpnclient3" via ...
... (interface doesn't exist)
Jul 20 09:27:06 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient4)
Jul 20 09:27:06 RT-AC3100-9488 rc_service: service 9740:notify_rc stop_vpnclient5
Jul 20 09:27:06 RT-AC3100-9488 rc_service: waitting "stop_vpnclient4" via ...
... (interface doesn't exist)
Jul 20 09:27:08 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient5)
... (interface doesn't exist)
Jul 20 09:27:19 RT-AC3100-9488 dropbear[10097]: Password auth succeeded for '???' from 192.168.1.160:54626
Jul 20 09:27:22 RT-AC3100-9488 rc_service: service 10338:notify_rc start_vpnclient3
Jul 20 09:27:22 RT-AC3100-9488 VPN: Client3 Active
Jul 20 09:27:22 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: start vpnclient3)
Jul 20 09:27:24 RT-AC3100-9488 ovpn-client3[10587]: OpenVPN 2.5.6 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 25 2022
Jul 20 09:27:24 RT-AC3100-9488 ovpn-client3[10587]: library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.08
...
Jul 20 09:27:27 RT-AC3100-9488 ovpn-client3[10588]: /usr/sbin/ip link set dev tun13 up
...
Jul 20 09:27:28 RT-AC3100-9488 openvpn: Forcing 192.168.1.0/24 to use DNS server x.x.x.x
Jul 20 09:27:31 RT-AC3100-9488 ovpn-client3[10588]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jul 20 09:27:31 RT-AC3100-9488 ovpn-client3[10588]: Initialization Sequence Completed
Jul 20 09:27:41 RT-AC3100-9488 rc_service: service 11551:notify_rc stop_vpnclient1
Jul 20 09:27:41 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)
Jul 20 09:27:41 RT-AC3100-9488 rc_service: service 11552:notify_rc stop_vpnclient2
Jul 20 09:27:41 RT-AC3100-9488 rc_service: waitting "stop_vpnclient1" via ...
... (interface doesn't exist)
Jul 20 09:27:43 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient2)
...
Jul 20 09:27:45 RT-AC3100-9488 rc_service: service 11689:notify_rc stop_vpnclient3
Jul 20 09:27:45 RT-AC3100-9488 rc_service: waitting "stop_vpnclient2" via ...
... (interface doesn't exist)
Jul 20 09:27:46 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient3)
Jul 20 09:27:46 RT-AC3100-9488 ovpn-client3[10588]: event_wait : Interrupted system call (code=4)
Jul 20 09:27:46 RT-AC3100-9488 ovpn-client3[10588]: SIGTERM received, sending exit notification to peer
Jul 20 09:27:47 RT-AC3100-9488 rc_service: service 11828:notify_rc stop_vpnclient4
Jul 20 09:27:47 RT-AC3100-9488 rc_service: waitting "stop_vpnclient3" via ...
Jul 20 09:27:51 RT-AC3100-9488 ovpn-client3[10588]: ovpn-route-pre-down tun13 1500 1624 x.x.x.x 255.255.254.0 init
Jul 20 09:27:51 RT-AC3100-9488 ovpn-client3[10588]: Closing TUN/TAP interface
Jul 20 09:27:51 RT-AC3100-9488 ovpn-client3[10588]: /usr/sbin/ip addr del dev tun13 x.x.x.x/23
Jul 20 09:27:51 RT-AC3100-9488 ovpn-client3[10588]: ovpn-down 3 client tun13 1500 1624 x.x.x.x 255.255.254.0 init
Jul 20 09:27:51 RT-AC3100-9488 openvpn-routing: Configured killswitch on VPN client 3
Jul 20 09:27:51 RT-AC3100-9488 ovpn-client3[10588]: SIGTERM[soft,exit-with-notification] received, process exiting
... (interface doesn't exist)
Jul 20 09:27:53 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient4)
...
Jul 20 09:27:54 RT-AC3100-9488 rc_service: service 12039:notify_rc stop_vpnclient5
Jul 20 09:27:54 RT-AC3100-9488 rc_service: waitting "stop_vpnclient4" via ...
... (interface doesn't exist)
Jul 20 09:27:55 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient5)
... (interface doesn't exist)
Jul 20 09:28:09 RT-AC3100-9488 rc_service: service 12772:notify_rc start_vpnclient2
Jul 20 09:28:09 RT-AC3100-9488 custom_script: Running /jffs/scripts/service-event (args: start vpnclient2)
Jul 20 09:28:09 RT-AC3100-9488 VPN: Client2 Active

I'll keep testing.

 

[Viktor Jaep]

Very nice!

@Viktor Jaep OK...happened again. This time, something slightly different. Before, the router became unresponsive and the VPN client that was being selected/started just kept retrying endlessly to connect while the internet connection was down. Now, when the internet connection came back up, with VPNMON running, it seemed that either VPNMON did not recognize that the internet connection had come back up or did and selected another VPN client to start but did not recognize that it had started...or both.

This is from the VPNMON log:



and on and on...

In the VPNMON GUI, after the WAN check and then the selection, the GUI was redrawn but it did not show that a VPN client was active. It only showed the ping time in ms where all 5 slots were grey. It also did not recognize that the WAN connection was restored.

After stopping and restarting VPNMON it showed that the WAN connection was up and that the slot was active. One thing I noticed in the VPNMON interface before restarting it was that near the top beside VPN State, it showed that one of the VPN slots had a 1 status and not 0 or 2. After restarting VPNMON, one of the slots showed a 2.

The syslogs before were not useful since the VPN client was just trying to restart. This time, the General syslog is showing what it seems that VPNMON is doing...it shows the VPN client that was selected being started successfully, and then what looks like the VPNMON reset happening. Here's a portion of the log showing what's happening. This keeps repeating:


I'll keep testing.

Ahhh... I think I see the conflict here. Could it be that the ChkWAN script is killing your vpn clients? Then VPNMON-R2 notices that its down, and tries to reconnect... then ChkWAN does it again. Perhaps ChkWAN is the script that is keeps trying to reconnect the VPN connection? Needless to say... there's definitely conflict here. Maybe... It's hard to tell from the syslog if ChkWAN is killing VPN connections, or if VPNMON-R2 is?

Perhaps, disable ChkWAN for a bit, and see if the behavior goes away? Really need to go through a series of troubleshooting steps... like disable all scripts, including VPNMON... check the settings for each of your VPN client slots. Are they all the same? When you enable the slider to "ON", does it work? Then slowly start introducing scripts to see how they might be altering your system behavior.

If there's a status of 1, then your WAN connection is not connected... and is in a state of trying to reconnect. VPNMON should at that point be in a WAN down page, and intermittently trying to reconnect if it sees that the state is back to 2?

EDIT: I just took a quick glance at the chkwan script, and didn't see any mention of vpn in it... so it probably isn't killing VPN connections.

 

[Kal1975]

The ChkWAN script only pings a few times to see if the WAN is up. When it is not, it restarts the WAN. I just checked and it does no handling of the VPNs. It just tries to reset/restart the WAN interface. Not sure whether there's a conflict or not but I don't think so.

I was thinking about a couple of things. First, what does the 1 state for the VPN mean again? Second, is it possible that VPNMON isn't waiting long enough for the VPN client to completely start before determining there is an issue with it? Is it checking for a state of 2 for the VPN client?

I think I found a way to simulate this. VPNMON should be running. Turn off your internet connection manually from the router GUI. Wait a bit for VPNMON to see it is down. Then turn the internet connection back on manually through the router GUI. Screen captures showing what happened then:

Not sure if you can recreate it.

 

[Viktor Jaep]

The ChkWAN script only pings a few times to see if the WAN is up. When it is not, it restarts the WAN. I just checked and it does no handling of the VPNs. It just tries to reset/restart the WAN interface. Not sure whether there's a conflict or not but I don't think so.

I was thinking about a couple of things. First, what does the 1 state for the VPN mean again? Second, is it possible that VPNMON isn't waiting long enough for the VPN client to completely start before determining there is an issue with it? Is it checking for a state of 2 for the VPN client?

I think I found a way to simulate this. VPNMON should be running. Turn off your internet connection manually from the router GUI. Wait a bit for VPNMON to see it is down. Then turn the internet connection back on manually through the router GUI. Screen captures showing what happened then:



Not sure if you can recreate it.

I've been able to test and simulate this by turning off my modem, as well as unplugging the cable from the router, or rebooting the modem... all scenarios end up allowing VPNMON to recognize and recover from a WAN outage. I can't say I ever tried this method of turning off the WAN connection within the GUI, so I will give that a go as well. I didn't see any screen captures? Could you please repost those?

Sorry... VPN State = 1 means the VPN Connection is trying to reconnect. So that means the WAN is up, and it's trying to make that connection, and perhaps getting stuck? If you see that it's successful on some slots, but not others... then it's a good idea to spend some time troubleshooting the settings on those trouble slots, and make sure they can actually connect on their own. You may need to reimport a config file, and compare settings from one slot to another?

 

[Kal1975]

Just added the screen captures back.

So, when VPNMON is showing the client selected/started, it actually does get started when I view in the router GUI. However, when VPNMON loops again, it thinks the WAN is still down and then does a RESET and then selects another random slot.

If you look at the screen captures, it shows the VPN is active at the top of the screen but then when doing the WAN check, it thinks the WAN is down...and keeps going on and on like that.

I was thinking about this and noted that when this happens, if I stop VPNMON and restart it, everything starts working again. That leads me to think it's some state or check that has isn't getting refreshed or an additional check that needs to happen. The main thing is why does it still think the WAN is down after it comes back up...and after starting a random VPN client, why doesn't it recognize that it has started.

I'll keep testing and I'll try running without ChkWAN and post results.

 

[Viktor Jaep]

Just added the screen captures back.

So, when VPNMON is showing the client selected/started, it actually does get started when I view in the router GUI. However, when VPNMON loops again, it thinks the WAN is still down and then does a RESET and then selects another random slot.

If you look at the screen captures, it shows the VPN is active at the top of the screen but then when doing the WAN check, it thinks the WAN is down...and keeps going on and on like that.

I was thinking about this and noted that when this happens, if I stop VPNMON and restart it, everything starts working again. That leads me to think it's some state or check that has isn't getting refreshed or an additional check that needs to happen. The main thing is why does it still think the WAN is down after it comes back up...and after starting a random VPN client, why doesn't it recognize that it has started.

I'll keep testing and I'll try running without ChkWAN and post results.

Thanks for those screenshots... that's actually very interesting. Even after issuing a kill command to your VPN clients, your VPN Slot #2 remained in a "connecting" state, and trying to start VPN Slot #3 at the same time. It's showing the WAN as connected - being in state = 2. Do you have any syslogs from that same time that show what was happening with VPN #2?

There may very well be a variable that's not getting refreshed in this particular situation. I'll definitely will try resetting the WAN from the slider switch in the GUI today to see if I can replicate this. Thanks!!

 

[Kal1975]

The portion of the syslog in post #84 shows this, I believe. The timestamps from the VPNMON log and the syslog correspond to what is happening.

 

[Viktor Jaep]

The portion of the syslog in post #84 shows this, I believe. The timestamps from the VPNMON log and the syslog correspond to what is happening.

Didn't see a lot of info regarding VPN #2. If it was in a continual "connecting" state, I would think there would be quite a bit of chatter about it... Or perhaps the process froze? There's no telling. Would you mind please giving Beta2 a try below? I added a routine during the reset that waits to make sure all VPN Client Slot States = 0 before continuing... It will indicate on-screen what all the states are that it's waiting for to reset to 0.

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.1b2.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

 

[Viktor Jaep]

The portion of the syslog in post #84 shows this, I believe. The timestamps from the VPNMON log and the syslog correspond to what is happening.

Hey @Kal1975 ... So just to let you know the results of this test, sliding the WAN switch to off from the router GUI itself... it identified that both WAN connections were down, then starting marking each VPN connection as "OFFLINE". It got busy doing the WAN check, and failed with a different error message that I'll try to sort out, but as soon as the WAN came back up, it went through its regular reset routine, and was back in working order without any interactions from me...

 

[Viktor Jaep]

Another Beta 3 to play with... further enhanced and troubleshot the WAN down scenario, and seems to be working quite well! Please give it a shot, @Kal1975

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.1b3.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

v2.1b3
* FIXED: Changed some of the logic of the WAN down scenario, and seems to be transitioning much smoother through the various stages of dealing with a lost connection.

 

[Viktor Jaep]

Happy Friday! Doing a 1-2 punch with both RTRMON and VPNMON-R2 today... so you can enjoy the weekend with new toys and features. Big changes and additions happened on the config menu! Also, major strides made in the detection and recovery of a WAN failure... Hoping to play a little more with dual-wan scenarios this weekend, so more good things to come...

VPNMON-R2 v2.1 - (July 22, 2022)
- ADDED: Completely reworked the setup/config menus to make the look/feel/act like RTRMON's. The hope was to simplify the process, allowing one to pick and choose settings to configure, instead of having to run down a long laundry list of configuration questions. I have done away with the loading of current config values as "defaults" when hitting the enter button, as it would be fairly easy to scroll up and see what value you had in place if need be. Enter on a blank line now assumes you want the system default.
- ADDED: An extra round of VPN client kill commands when the router detects WAN trouble, just to make sure it pre-emptively kills everything incase these VPN clients try to reconnect while the WAN is down.
- FIXED: Vastly reworked the logic of the WAN down scenario, and seems to be transitioning much smoother through the various stages of dealing with a lost connection. Definitely game-changing!!

Download link:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.1.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

 

[Stephen Harrington]

Something a bit screwy with my setup on 2.1 @Viktor Jaep, seems to be unable to get the dns values.
Can I get you some "nvram show" values to help troubleshoot?

 

[Viktor Jaep]

Something a bit screwy with my setup on 2.1 @Viktor Jaep, seems to be unable to get the dns values.
Can I get you some "nvram show" values to help troubleshoot?

View attachment 42995

Yes please, @Stephen Harrington! Could you please run this?

nvram show wan_dns

 

[Stephen Harrington]

admin@AsusRouter:/tmp/home/root# nvram get wan_dns
192.168.2.1

That would be totally not it!

 

[Viktor Jaep]

admin@AsusRouter:/tmp/home/root# nvram get wan_dns
192.168.2.1

That would be totally not it!

Just testing you... how about this:

ram1="$(nvram get wan_dns | awk '{print $1}')"
ram2="$(nvram get wan_dns | awk '{print $2}')"
echo $ram1 $ram2

 

[Stephen Harrington]

admin@AsusRouter:/tmp/home/root# ram1="$(nvram get wan_dns | awk '{print $1}')"
admin@AsusRouter:/tmp/home/root# ram2="$(nvram get wan_dns | awk '{print $2}')"
admin@AsusRouter:/tmp/home/root# echo $ram1 $ram2
192.168.2.1

 

[Viktor Jaep]

admin@AsusRouter:/tmp/home/root# ram1="$(nvram get wan_dns | awk '{print $1}')"
admin@AsusRouter:/tmp/home/root# ram2="$(nvram get wan_dns | awk '{print $2}')"
admin@AsusRouter:/tmp/home/root# echo $ram1 $ram2
192.168.2.1

OK... stand by while I change my strategy on this... Will you be around within the next hour? The family is calling me for dinner...