VPNMON VPNMON-R3 v1.3.7 -Oct 20, 2024- Monitor WAN/Dual-WAN/OpenVPN Health & Reset Multiple OpenVPN Connections (Now available in AMTM!)

[Viktor Jaep]

New VPNMON-R3 v1.03 is out today with new pause functionality around the reset courtesy of @salvo... thanks for the suggestion!

What's new!
v1.03 - ADDED: When VPNMON-R3 is executing a scheduled -RESET, the main UI will enter a 'pause' state, giving some feedback that a vpn reset is currently underway, and will retry to resume normal operations every 15 secs. Thanks to @salvo for the suggestion!
- ADDED: More checks and stability added to ensuring values returning from the ping functions are valid, and hoping to catch any errors before returning the occasional 'unexpected token' error as found by @salvo.
- FIXED: Noticed that the timer loop was actually taking 2x as long to complete... I knew seconds couldn't take that long, and wasn't going crazy afterall. Fixed.

Download Link (execute below, or update directly within VPNMON-R3!):

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.03.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"

Significant Screenshots:

Showing the pause screen the main UI would display when another external -RESET is happening

 

[salvo]

New VPNMON-R3 v1.03 is out today with new pause functionality around the reset courtesy of @salvo... thanks for the suggestion!

Works fine so far Thanks for the very quick fix.

The script is really great I must say !

 

[Viktor Jaep]

Works fine so far Thanks for the very quick fix.

The script is really great I must say !

You're very welcome! And thank you -- I've made the full transition to R3 myself for a good month or so now since implementing the Unbound integration... it's been working great.

It's been surprising to see how unstable some of these NordVPN servers are out there (or my WAN connection I suppose)... on some days, they will not respond and cause a reset about 6x during the day, other times, the -RESET is the only thing that was active.

 

[salvo]

It's been surprising to see how unstable some of these NordVPN servers are out there (or my WAN connection I suppose)... on some days, they will not respond and cause a reset about 6x during the day, other times, the -RESET is the only thing that was active.

You know, actually today just happened that connection says "no problem" but I was not able to ping from any client

VPNMON-R3 - v1.03 | (S)how/(H)ide Operations Menu   Sun Jan  7 16:24:45 CET 2024


  Slot | Mon |  Svrs  | Health | VPN State    | Public VPN IP   | Ping-->VPN | City Exit / Time
-------|-----|--------|--------|--------------|-----------------|------------|-----------------------
  VPN1 | [X] | [0005] | [ OK ] | Connected    | 185.250.215.001 | [0028.528] | Prague: 0d 00h:46m
  VPN2 | [X] | [0005] | [ OK ] | Connected    | 185.250.215.164 | [0026.700] | Prague: 0d 00h:46m
  VPN3 | [X] | [0005] | [ OK ] | Connected    | 193.142.203.030 | [0032.072] | Prague: 0d 00h:45m
-------|-----|--------|--------|--------------|-----------------|------------|-----------------------


  10s / 16% [e=Exit] [Selection?  ]

This is BEFORE -reset switch

odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
curl: (7) Failed to connect to ip-api.com port 80 after 34 ms: Connection refused
odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
curl: (7) Failed to connect to ip-api.com port 80 after 34 ms: Connection refused
odroid@server:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.59 icmp_seq=1 Destination Port Unreachable
From 192.168.1.59 icmp_seq=2 Destination Port Unreachable
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1033ms

odroid@server:~$ ping www.google.com
PING www.google.com (142.251.36.132) 56(84) bytes of data.
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=1 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=2 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=3 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=4 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=5 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=6 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=7 Destination Port Unreachable
^C
--- www.google.com ping statistics ---
7 packets transmitted, 0 received, +7 errors, 100% packet loss, time 6008ms

odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
curl: (7) Failed to connect to ip-api.com port 80 after 42 ms: Connection refused

This is AFTER -reset switch

odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
CZ,Prague,Tefincom S.A.,185.250.215.1
odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
CZ,Prague,Tefincom S.A.,185.250.215.1

Do you have any recommendations on what more to address in case I experience similar behavior again ? Maybe it could help in improving the script and detecting the problem. Looks like pinging the ASUS interface is not that reliable as pining from client, see below what workaround I use to address this issue and so far working fine.

Script pinging 8.8.8.8 server from client (sending MQTT msg to Home Assistant) and then based on the feedback HA triggers -reset via command line.

ssh -i /config/ssh/ssh_asus_private_key ABC@192.168.123.19 /jffs/scripts/vpnmon-r3.sh -reset

 

[Viktor Jaep]

You know, actually today just happened that connection says "no problem" but I was not able to ping from any client

VPNMON-R3 - v1.03 | (S)how/(H)ide Operations Menu   Sun Jan  7 16:24:45 CET 2024


  Slot | Mon |  Svrs  | Health | VPN State    | Public VPN IP   | Ping-->VPN | City Exit / Time
-------|-----|--------|--------|--------------|-----------------|------------|-----------------------
  VPN1 | [X] | [0005] | [ OK ] | Connected    | 185.250.215.001 | [0028.528] | Prague: 0d 00h:46m
  VPN2 | [X] | [0005] | [ OK ] | Connected    | 185.250.215.164 | [0026.700] | Prague: 0d 00h:46m
  VPN3 | [X] | [0005] | [ OK ] | Connected    | 193.142.203.030 | [0032.072] | Prague: 0d 00h:45m
-------|-----|--------|--------|--------------|-----------------|------------|-----------------------


  10s / 16% [e=Exit] [Selection?  ]

This is BEFORE -reset switch

odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
curl: (7) Failed to connect to ip-api.com port 80 after 34 ms: Connection refused
odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
curl: (7) Failed to connect to ip-api.com port 80 after 34 ms: Connection refused
odroid@server:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.59 icmp_seq=1 Destination Port Unreachable
From 192.168.1.59 icmp_seq=2 Destination Port Unreachable
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1033ms

odroid@server:~$ ping www.google.com
PING www.google.com (142.251.36.132) 56(84) bytes of data.
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=1 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=2 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=3 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=4 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=5 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=6 Destination Port Unreachable
From RT-AX86U-3E18 (192.168.1.59) icmp_seq=7 Destination Port Unreachable
^C
--- www.google.com ping statistics ---
7 packets transmitted, 0 received, +7 errors, 100% packet loss, time 6008ms

odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
curl: (7) Failed to connect to ip-api.com port 80 after 42 ms: Connection refused

This is AFTER -reset switch

odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
CZ,Prague,Tefincom S.A.,185.250.215.1
odroid@server:~$ curl http://ip-api.com/csv/?fields=countryCode,city,isp,query
CZ,Prague,Tefincom S.A.,185.250.215.1

Do you have any recommendations on what more to address in case I experience similar behavior again ? Maybe it could help in improving the script and detecting the problem. Looks like pinging the ASUS interface is not that reliable as pining from client, see below what workaround I use to address this issue and so far working fine.

Script pinging 8.8.8.8 server from client (sending MQTT msg to Home Assistant) and then based on the feedback HA triggers -reset via command line.

ssh -i /config/ssh/ssh_asus_private_key ABC@192.168.123.19 /jffs/scripts/vpnmon-r3.sh -reset

What host do you have setup to ping to in your config? Default is 8.8.8.8. Each ping made is done through each VPN tunnel/interface to determine if the tunnel is viable. It actually also does a curl as well.

 

[salvo]

Yes, it is 8.8.8.8

(1) : Number of VPN Client Slots available         : 1 2 3
  (2) : Custom PING host to determine VPN health     : 8.8.8.8
  (3) : Custom Event Log size (rows)                 : 2000
  (4) : Unbound DNS Lookups over VPN Integration     : Disabled
  (5) : Refresh Custom Server Lists on -RESET Switch : Enabled

Actually, if this situation occurs again, let me know what commands to execute to deep dive into this. For now, the only way I am 100% sure tunnel is CONNECTED is ping from the client.

 

[Viktor Jaep]

Yes, it is 8.8.8.8

(1) : Number of VPN Client Slots available         : 1 2 3
  (2) : Custom PING host to determine VPN health     : 8.8.8.8
  (3) : Custom Event Log size (rows)                 : 2000
  (4) : Unbound DNS Lookups over VPN Integration     : Disabled
  (5) : Refresh Custom Server Lists on -RESET Switch : Enabled

Actually, if this situation occurs again, let me know what commands to execute to deep dive into this. For now, the only way I am 100% sure tunnel is CONNECTED is ping from the client.

I'm reasonably sure that if you ping from your console, that you're going out directly over your WAN connection. You would need to add some more qualifiers to your ping statement to make it go out over your VPN tunnel, and specify the TUN1x interface. It sounds to me like some routing was messed up on your router that was preventing your pings/resolution from working right over the WAN... the VPN reset caused a reset of your VPN routing service which helped correct your resolution issue post-reset.

 

[Viktor Jaep]

.Actually, if this situation occurs again, let me know what commands to execute to deep dive into this. For now, the only way I am 100% sure tunnel is CONNECTED is ping from the client.

This is the command you'd want to use to ping across your VPN tunnels to test things next time something seems to be going south:

Replace tun11 with your VPN client tunnel number... client 1 = tun11, client 2 = tun12, client 3 = tun13, etc.

ping -I tun11 -c 3 -W 2 8.8.8.8

 

[cohomology]

I guess the point is, all servers sharing the same config parameters such as username, password,... can be stored in one server slot, am I correct?

 

[Viktor Jaep]

I guess the point is, all servers sharing the same config parameters such as username, password,... can be stored in one server slot, am I correct?

Correct. In fact, you could clone all 5 slots with the same config file, as the certificates and username/passwords are identical for each VPN server connection. It's just the address of the VPN server that will be different each time.

 

[cohomology]

Did anyone find the script super super laggy? Sometime it takes like one minute to enter the operation menu after I press "S".

 

[Viktor Jaep]

Did anyone find the script super super laggy? Sometime it takes like one minute to enter the operation menu after I press "S".

It's instantaneous for me after each keypress. What kind of equipment are you running? Any other cpu-intensive scripts running?

 

[cohomology]

It's instantaneous for me after each keypress. What kind of equipment are you running? Any other cpu-intensive scripts running?

I am running RT-AX88U non pro.

Only running dual wan monitor and diversion at the moment. It becomes super laggy when there’s even more than 600m free memory. Very weird indeed.

 

[Viktor Jaep]

I am running RT-AX88U non pro.

Only running dual wan monitor and diversion at the moment. It becomes super laggy when there’s even more than 600m free memory. Very weird indeed.

Assuming you've been looking at top/htop to do some troubleshooting on what's causing such a lag on your router? I'm running VPNMON-R3, RTRMON, WXMON, and PWRMON (all running continously in screen), as well as KILLMON and BACKUPMON.... everything running all at the same time at all times... and not seeing any lag. (in addition to Diversion, Unbound and Skynet)

 

[cohomology]

Yes I have. "top" is 90% idle when the scripts is super laggy.

BTW how does one restart the script?

 

[Viktor Jaep]

Yes I have. "top" is 90% idle when the scripts is super laggy.

Not sure what to tell you... have you tried stopping other scripts like the dual wan monitor and seeing if that has any effects? My top is usually 90%+ idle, and not experiencing any lag. In fact, you're the very first person that has ever complained about laggyness.

BTW how does one restart the script?

CTRL-C... then type "vpnmon-r3" again... (or if you're using screen, you'd type "vpnmon-r3 -screen")

 

[cohomology]

Wait, you saying that C-C actually termiates the script? I thought that the script runs in the background... No wonder I don't see it when 'ps'.

 

[Viktor Jaep]

Wait, you saying that C-C actually termiates the script? I thought that the script runs in the background... No wonder I don't see it when 'ps'.

Nope. In the foreground. You can make it run in the background with "screen".

 

[cohomology]

OK. Out of ideas for now and I am going to bed

 

[Ripshod]

I am running RT-AX88U non pro.

Only running dual wan monitor and diversion at the moment. It becomes super laggy when there’s even more than 600m free memory. Very weird indeed.

What are you using for a usb drive? How old is it? How long is it since you checked/formatted it? How long is it since you did a factory reset on the router?
You can see from my signature what I'm running, without any noticeable lag even when I was running VPNMON-R3.

Edit:
Just uninstalled R2 for R3 to help diagnose and guess what? Still no lag.