What's new
  • 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!

VPNMON VPNMON-R3 v1.7.0 -Sep 20, 2025- Monitor OpenVPN/Wireguard WAN/Dual-WAN Health & Random Reset Multiple Connections (Available in AMTM!) - v1.8.0 Beta5

Perhaps it would be less confusing if under option 14 you removed the word "speed" and replaced it with another term such as "throughput" in both the option and the description of what is being measured. Just my two cents.
Great suggestion! Thanks @CaptainSTX
 
Great suggestion! Thanks @CaptainSTX
Your welcome. Incidentally when VPMON was improved to include monitoring WG VPN clients and it appeared that they were not as rock solid as I once thought they were, and I had to adjust VPMON to minimize the restarts and reduce the email notifications it turns out that the root of the problem was a new modem I put in service at about the same time. With the ISPs modem both my WAN and WG VPN connections are very stable.
 
Your welcome. Incidentally when VPMON was improved to include monitoring WG VPN clients and it appeared that they were not as rock solid as I once thought they were, and I had to adjust VPMON to minimize the restarts and reduce the email notifications it turns out that the root of the problem was a new modem I put in service at about the same time. With the ISPs modem both my WAN and WG VPN connections are very stable.
Man... Now I'm going to have to rip out all that code again! Lol

Nahhh! Glad to hear things are more stable for you with the equipment change! Out of my different WG providers I use, I can definitely tell that Nord has the most problems keeping a clean line going. I'm kinda glad I added the recovery timeouts, because that's really helped it from not reconnecting each time Nord had a hiccup.
 
VPNMON-R3 - v1.8.0b3

While getting things set-up after a router replacement I am seeing a [: bad number% ] next to the timer loop display when it
times out. I am also not seeing any rx/tx on the vpn slots. Should be seeing something on vpn1 slot for sure . Nothing is running thru the WG
slots yet.
 

Attachments

  • Screenshot 2025-10-06 130238.png
    Screenshot 2025-10-06 130238.png
    160.5 KB · Views: 20
VPNMON-R3 - v1.8.0b3

While getting things set-up after a router replacement I am seeing a [: bad number% ] next to the timer loop display when it
times out. I am also not seeing any rx/tx on the vpn slots. Should be seeing something on vpn1 slot for sure . Nothing is running thru the WG
slots yet.
That's definitely odd. Does it show any kind of 60 second counter? Can you show a copy of your .cfg file entries?

If the timer loop isn't even working, then you probably won't see any bandwidth stats. I need to take a look at my code to see if there's a requirement for a slot to be "monitored" before it shows these stats, or not. I will check this evening.
 
That's definitely odd. Does it show any kind of 60 second counter? Can you show a copy of your .cfg file entries?

If the timer loop isn't even working, then you probably won't see any bandwidth stats. I need to take a look at my code to see if there's a requirement for a slot to be "monitored" before it shows these stats, or not. I will check this evening.

@Viktor Jaep

The timer loop displays fine. It's just when it gets to 100% I get that bad number showing.
I have since finished setting up monitoring and it is still there.
 

Attachments

  • Screenshot 2025-10-06 142420.png
    Screenshot 2025-10-06 142420.png
    156.1 KB · Views: 20
  • vpnmon-r3.cfg.txt
    vpnmon-r3.cfg.txt
    818 bytes · Views: 10
@Viktor Jaep

The timer loop displays fine. It's just when it gets to 100% I get that bad number showing.
I have since finished setting up monitoring and it is still there.
Sounds like it might be a calculation issue on my end after the timer is up. I'll dive back into this and double-check everything.
 
VPNMON-R3 - v1.8.0b3

While getting things set-up after a router replacement I am seeing a [: bad number% ] next to the timer loop display when it
times out. I am also not seeing any rx/tx on the vpn slots. Should be seeing something on vpn1 slot for sure . Nothing is running thru the WG
slots yet.
@Viktor Jaep

Disregard my post about not seeing rx/tx data. It is showing fine now. My feeble mind neglected to recall you
had told me this is not that unusual .
 
Beta 4 is out with some fixes with many thanks to @CaptainSTX and @scootertramp!

What's new?
v1.8.0b4 - (October 6, 2025)
- MINOR:
Added more visibility to the main UI, and included both TX and RX stats for each connection. Please know, these stats are basically the average connection speed across the length of the timer. They may not be entirely 100% accurate, and are a close approximation of the speeds encountered during this period of time. At the moment, the RX ranges for Green = 0 - 100Mbps, Yellow = 100 - 250Mbps, Red = > 250Mbps. Config menu item #14 allows you to modify these values based on your own personal preferences and bandwidth. Separation between RX and TX thresholds has been added for those with asymmetrical internet connections, with thanks to @Stephen Harrington for the push in that direction! TX range defaults for Green = 0 - 15Mbps, Yellow = 15 - 25Mbps, Red = > 25Mbps.
- PATCH: Fixed a few small inconsistencies across the script.
- PATCH: Renamed "Connection Speed" to "Connection Throughput" to help clarify the purpose of the new RX/TX measurement information while in setup item #14. Thanks @CaptainSTX for the suggestion!
- PATCH: Fixed the "Bad Number:%" error. Thanks to @scootertramp for reporting that!

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

Significant Screenshots:

Connection Throughput change in the Config Menu:

1759795458102.png


... and in menu item #14 showing "Throughput" to set the various thresholds.

1759795528857.png
 
Initially looks great but did run into some wonkiness after doing a reset/reconnect. After the reset the rx/tx counters went to 0 for that slot. Wan still showing expected rx rate.
I tried stop/start vpnmon but no change. I will try to see if this repeats again later.
It did clear up sometime over night. That vpn slot is showing correct data this AM.
So I'm convinced something like this is happening... just based on what I'm seeing with this behavior.

1.) Everything is connected and working fine on the router
2.) VPN/WG connection goes wonky, and gets reset
3.) VPN routing service temporarily pushes clients through the WAN, or another connection
4.) VPN/WG connection gets re-established
5.) VPN routing service tries to push everything back onto your VPN/WG connection
6.) Clients are still connected through the WAN, until their routes time out, and migrate back to using the VPN/WG connection
7.) Once everything comes back over, normal speeds are observed again.

I just experienced an event where VPNMON detected a WAN outage, and killed all my VPN/WG connections. All clients were being routed over the WAN. Once everything came back up, that WAN traffic was still at the same level, and the VPN/WG connections were showing 0 both in VPNMON and RTRMON. I started seeing a little activity after a few minutes, but eventually after some time, speeds show as normal on both the VPN/WG connection and the WAN.

Really think that somehow clients are still pointing through the WAN until their connections timeout or something, and then route back over the VPN/WG connection again. Will keep looking into this a little deeper.
 
So I'm convinced something like this is happening... just based on what I'm seeing with this behavior.

1.) Everything is connected and working fine on the router
2.) VPN/WG connection goes wonky, and gets reset
3.) VPN routing service temporarily pushes clients through the WAN, or another connection
4.) VPN/WG connection gets re-established
5.) VPN routing service tries to push everything back onto your VPN/WG connection
6.) Clients are still connected through the WAN, until their routes time out, and migrate back to using the VPN/WG connection
7.) Once everything comes back over, normal speeds are observed again.

I just experienced an event where VPNMON detected a WAN outage, and killed all my VPN/WG connections. All clients were being routed over the WAN. Once everything came back up, that WAN traffic was still at the same level, and the VPN/WG connections were showing 0 both in VPNMON and RTRMON. I started seeing a little activity after a few minutes, but eventually after some time, speeds show as normal on both the VPN/WG connection and the WAN.

Really think that somehow clients are still pointing through the WAN until their connections timeout or something, and then route back over the VPN/WG connection again. Will keep looking into this a little deeper.
Sounds pretty reasonable. Since I can get good interface data with Prometheus Node Exporter now.
I'll have to see if using killswitch would maybe prove that out.
 
Sounds pretty reasonable. Since I can get good interface data with Prometheus Node Exporter now.
I'll have to see if using killswitch would maybe prove that out.
@Viktor Jaep


Ran a first past without killswitch using two TV's streaming local programming. Ran a manual reset of vpn slot 1.
The drop off at the end was when I switched off one of the TV's to see which was no longer using VPN.
If I get a chance later I will try with killswitch enabled.

Shut-off/on the offending TV for a moment and started to see RX data on the slot 1 interface.
 

Attachments

  • Screenshot 2025-10-09 165526.png
    Screenshot 2025-10-09 165526.png
    155.4 KB · Views: 14
  • Screenshot 2025-10-09 150533.png
    Screenshot 2025-10-09 150533.png
    153.7 KB · Views: 14
  • Screenshot 2025-10-09 172158.png
    Screenshot 2025-10-09 172158.png
    133.8 KB · Views: 14
Last edited:
@Viktor Jaep


Ran a first past without killswitch using two TV's streaming local programming. Ran a manual reset of vpn slot 1.
The drop off at the end was when I switched off one of the TV's to see which was no longer using VPN.
If I get a chance later I will try with killswitch enabled.

Shut-off/on the offending TV for a moment and started to see RX data on the slot 1 interface.
@Viktor Jaep

Round two with killswitch enabled worked perfectly.
Started out a bit rough with a wan down event. Need to scrub router logs for any hint.
VPNMON handled it automagically.
 

Attachments

  • Screenshot 2025-10-09 200539.png
    Screenshot 2025-10-09 200539.png
    109.7 KB · Views: 14
  • Screenshot 2025-10-09 201103.png
    Screenshot 2025-10-09 201103.png
    124.8 KB · Views: 17
Awesome. If it fails 9 times in a row, it would reset in that case. There's a good likelihood it'll work itself out, unless something catastrophic happened to the server, connection or VPN provider. ;)
I am currently running 1.80b4 and I appreciate your efforts in continuously improving this app. One additional feature I would find useful is if you added the option to manually reset the uptime counters. Currently it only seem to update a counter if the app is called upon to reset a tunnel. Rebooting the router doesn't necessarily reset the counter if the reboot process doesn't exceed the reset parameters. Also in my case I recently activated a WG client that I had turned off and hadn't used for over a month. In VPMON it shows this client has been up for longer than the WAN as it is calculating this WG client's uptime from the last reset of this particular client.

IMHO it wouldn't be necessary to have the option to reset each of the timers individually but still very useful to have a global reset of all 11 or 12 counters. Again, thanks for your efforts.
 
I am currently running 1.80b4 and I appreciate your efforts in continuously improving this app. One additional feature I would find useful is if you added the option to manually reset the uptime counters. Currently it only seem to update a counter if the app is called upon to reset a tunnel. Rebooting the router doesn't necessarily reset the counter if the reboot process doesn't exceed the reset parameters. Also in my case I recently activated a WG client that I had turned off and hadn't used for over a month. In VPMON it shows this client has been up for longer than the WAN as it is calculating this WG client's uptime from the last reset of this particular client.

IMHO it wouldn't be necessary to have the option to reset each of the timers individually but still very useful to have a global reset of all 11 or 12 counters. Again, thanks for your efforts.
Sounds like a great addition @CaptainSTX! I'll add this to my list. :)
 
Beta 5 is out, along with a great suggestion from @CaptainSTX! I think we're nearing the end of changes to this release, and will be getting this one out the door soon. Please let me know how this works out, or if there are any other suggested changes! :)

What's new!?
v1.8.0b5 - (October 19, 2025)
- MINOR:
Added more visibility to the main UI, and included both TX and RX stats for each connection. Please know, these stats are basically the average connection speed across the length of the timer. They may not be entirely 100% accurate, and are a close approximation of the speeds encountered during this period of time. At the moment, the RX ranges for Green = 0 - 100Mbps, Yellow = 100 - 250Mbps, Red = > 250Mbps. Config menu item #14 allows you to modify these values based on your own personal preferences and bandwidth. Separation between RX and TX thresholds has been added for those with asymmetrical internet connections, with thanks to @Stephen Harrington for the push in that direction! TX range defaults for Green = 0 - 15Mbps, Yellow = 15 - 25Mbps, Red = > 25Mbps.
- MINOR: Significantly changed the Slot (M)onitoring screen, and have now added the capability of resetting individual slot connection times. This might be useful for those running WG considering that after a router reboot, the WG connections will complete before VPNMON-R3 is started up, so it has no idea that the tunnels were reset. I might get fancy down the road and look at router uptime as well, but for now, this will suffice. Thanks to @CaptainSTX for coming up with this great idea!
- PATCH: Fixed a few small inconsistencies across the script.
- PATCH: Renamed "Connection Speed" to "Connection Throughput" to help clarify the purpose of the new RX/TX measurement information while in setup item #14. Thanks @CaptainSTX for the suggestion!
- PATCH: Fixed the "Bad Number:%" error. Thanks to @scootertramp for reporting that!

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

Significant Screenshots:

Additions to the VPN/WG Client Slot Monitoring screen, now giving you the option of resetting connected time if needed.

1760877191974.png
 
Beta 5 is out, along with a great suggestion from @CaptainSTX! I think we're nearing the end of changes to this release, and will be getting this one out the door soon. Please let me know how this works out, or if there are any other suggested changes! :)

What's new!?
v1.8.0b5 - (October 19, 2025)
- MINOR:
Added more visibility to the main UI, and included both TX and RX stats for each connection. Please know, these stats are basically the average connection speed across the length of the timer. They may not be entirely 100% accurate, and are a close approximation of the speeds encountered during this period of time. At the moment, the RX ranges for Green = 0 - 100Mbps, Yellow = 100 - 250Mbps, Red = > 250Mbps. Config menu item #14 allows you to modify these values based on your own personal preferences and bandwidth. Separation between RX and TX thresholds has been added for those with asymmetrical internet connections, with thanks to @Stephen Harrington for the push in that direction! TX range defaults for Green = 0 - 15Mbps, Yellow = 15 - 25Mbps, Red = > 25Mbps.
- MINOR: Significantly changed the Slot (M)onitoring screen, and have now added the capability of resetting individual slot connection times. This might be useful for those running WG considering that after a router reboot, the WG connections will complete before VPNMON-R3 is started up, so it has no idea that the tunnels were reset. I might get fancy down the road and look at router uptime as well, but for now, this will suffice. Thanks to @CaptainSTX for coming up with this great idea!
- PATCH: Fixed a few small inconsistencies across the script.
- PATCH: Renamed "Connection Speed" to "Connection Throughput" to help clarify the purpose of the new RX/TX measurement information while in setup item #14. Thanks @CaptainSTX for the suggestion!
- PATCH: Fixed the "Bad Number:%" error. Thanks to @scootertramp for reporting that!

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

Significant Screenshots:

Additions to the VPN/WG Client Slot Monitoring screen, now giving you the option of resetting connected time if needed.

View attachment 68450
The time connected reset function works and accomplishes what I suggested. Thank you. Before going final you might want to consider modifying the throughput calculation. While it works it doesn't provide any useful information to me in its present form. To minimize restarts I have been using longer timer intervals of up to 180 seconds. Since data flows tend to be bursty when it divides the total data flow on a tunnel by 60, 90, 180 the result is often a very small number. In my case I would find total throughput on a tunnel between resets a more useful statistic. See if anyone else has a different opinion.
 
The time connected reset function works and accomplishes what I suggested. Thank you. Before going final you might want to consider modifying the throughput calculation. While it works it doesn't provide any useful information to me in its present form. To minimize restarts I have been using longer timer intervals of up to 180 seconds. Since data flows tend to be bursty when it divides the total data flow on a tunnel by 60, 90, 180 the result is often a very small number. In my case I would find total throughput on a tunnel between resets a more useful statistic. See if anyone else has a different opinion.
I can see where you're coming from. I have my interval set at 60 seconds, and retries set to 3x. I mainly use it as an indicator to see that something is happening on the network that might require my attention... for instance, kids hogging the bandwidth doing mass-downloads, some streaming happening, etc. and not some malware doing mass exfiltration. ;)
 
I can see where you're coming from. I have my interval set at 60 seconds, and retries set to 3x. I mainly use it as an indicator to see that something is happening on the network that might require my attention... for instance, kids hogging the bandwidth doing mass-downloads, some streaming happening, etc. and not some malware doing mass exfiltration. ;)
I agree the most important and most useful feature of this app is to keep VP tunnels up and confirm they are running. I don't use a kill switch as while security is important having an Internet connection is more important for devices such as my thermostat and security cameras which I like to be able to monitor when traveling. Other functions and data from the app are interesting, but not vital. WG seems to be much more reliable the OPENVPN but it is still nice to have confirmation that the tunnel is up.
 

Similar threads

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!

Staff online

Back
Top