VPNMON VPNMON-R3 v1.5.0 -Aug 3, 2025- Monitor OpenVPN/Wireguard WAN/Dual-WAN Health & Random Reset Multiple Connections (Available in AMTM!)

[Stephen Harrington]

Sheesh... After all this, I should have called it VPNMON-R3000 v4.0.0!

Got yourself in a bit of a trap there didn't you?
Would have thought this was the perfect time to just call it VPNMON and be done with it..


Thanks @Viktor Jaep for all your ongoing hard work on your plugins, it IS much appreciated!

 

[Viktor Jaep]

Got yourself in a bit of a trap there didn't you?
Would have thought this was the perfect time to just call it VPNMON and be done with it..

I actually going to start feeling out "VPNMON-R3D2" and see how that flies.

Thanks @Viktor Jaep for all your ongoing hard work on your plugins, it IS much appreciated!

Happy to contribute! Plus it's fun... keeps me busy, and distracted.

 

[iTyPsIDg]

Weird update issue, but not a big deal.

Or is that expected? It looks like a downgrade even though it isn't.

 

[Viktor Jaep]

Weird update issue, but not a big deal.
View attachment 67142

Or is that expected? It looks like a downgrade even though it isn't.

It's an upgrade... v1.5.0 Stable > v1.5.0 Beta 8

 

[JTnola]

I know I’m probably blanking on something obvious, but what does “RL” mean? Thanks!

 

[Viktor Jaep]

I know I’m probably blanking on something obvious, but what does “RL” mean? Thanks! View attachment 67156

RL = Rate Limiting (Red=Disabled)

- PATCH: Implemented a formal email rate limiter function that controls a user-configurable allowed number of emails to be sent per hour. This option is configured under AMTM Email Not(i)fications, and allows you to choose a number between 1 and 9999, with 0 having this function disabled. When email events fire off, you will see a system message on the bottom of your screen indicating how many emails have been sent thusfar this past hour, and whether any rate limiting is in effect. An indicator is displayed when the Operations Menu is displayed on the very top-right. RL (red) = disabled, and RL:<number of emails>/h shows the number of emails allowed per hour.

 

[JTnola]

RL = Rate Limiting (Red=Disabled)

- PATCH: Implemented a formal email rate limiter function that controls a user-configurable allowed number of emails to be sent per hour. This option is configured under AMTM Email Not(i)fications, and allows you to choose a number between 1 and 9999, with 0 having this function disabled. When email events fire off, you will see a system message on the bottom of your screen indicating how many emails have been sent thusfar this past hour, and whether any rate limiting is in effect. An indicator is displayed when the Operations Menu is displayed on the very top-right. RL (red) = disabled, and RL:<number of emails>/h shows the number of emails allowed per hour.

Oh. Thank you!!!! (Ps- It shows even if you have email notifications disabled altogether. Not that it matters at all … just letting you know, etc.)

 

[Viktor Jaep]

Oh. Thank you!!!! (Ps- It shows even if you have email notifications disabled altogether. Not that it matters at all … just letting you know, etc.)

Great idea, @JTnola... I can make it disappear completely if that feature isn't even enabled. Good call.

 

[Martinski]

RL = Rate Limiting (Red=Disabled)

- PATCH: Implemented a formal email rate limiter function that controls a user-configurable allowed number of emails to be sent per hour. This option is configured under AMTM Email Not(i)fications, ...

Just to clear any possible misunderstandings or confusion, AMTM itself is not sending the email notifications. The emails are composed, formatted, and then sent using functions provided by the custom email library script, which reads the AMTM email configuration file (previously set up by the user) to obtain specific parameters to create the email header and compose the curl command to send the email.

 

[fourty6and2]

Thanks for enhancing this to support WG!

Does the unbound over vpn work with WG? Having some difficulty with it but guessing I set it up wrong.

 

[Viktor Jaep]

Thanks for enhancing this to support WG!

Does the unbound over vpn work with WG? Having some difficulty with it but guessing I set it up wrong.

Thank you! Yeah unfortunately it only works with a dedicated VPN connection at the moment. I do have plans to try to reverse engineer this component and get it working over WG as well. That's my next big task.

 

[ZebMcKayhan]

I do have plans to try to reverse engineer this component and get it working over WG as well. That's my next big task.

From what I have seen, the current fix involves fwmark based routing, similar to what was used in X3MRouting and now also in "Domain VPN routing". This method is fragile and conflicts with AIProtect as both are using FWMark and currently there are no bits left unused. The current scheme would have to be expanded with more bits to allow for both OpenVPN and Wireguard selection which further increases the risk for conflict.

Ive remember seeing this function in Unbound Manager and if I remember correctly it sets in unbound.conf:

#outgoing-interface: xxx.xxx.xxx.xxx

to

outgoing-interface: <vpn ipv4>

and then rp_filter to loose (or off) for that interface which FW already does for openVPN but not necessarily for Wireguard. Alternatively use the VPN Director rule to send that interface to wgcX as you already do with ping and speed test.
this would force Unbound to only use that specific interface. but for this to work it has to be set whenever the tunnel starts followed by unbound restart and reset if the tunnel is stopped. otherwise you may loose DNS if the tunnel stops, breaks or fails to start. in order to do this, VPN-start and stop hook files would be used to tell Unbound Manager what to do.

again, it's tricky and potentially fragile.

Im doing it differently. I simply edit unbound.conf (command "vx" inside Unbound manager) and set

outgoing-interface: 192.168.50.1

so, I set it to my LAN ipv4.
This wont really do anything normally. Router would itself typically only use this source address when talking to lan clients and additionally for the few apps that are bound to LAN interface (like the web UI).
The plan is to route this IP to our Wireguard interface of choice, but in order to do that without messing up WebUI for example if are using the killswitch, we make a VPNDirector rule to make sure Router to LAN communication uses Main route table so it wont be affected by any killswitch or whatever is going on in the policy route table:
LocalIP: 192.168.50.1
RemoteIP: 192.168.0.0/16
IFace: WAN

with this rule we will make sure that we are not affecting any local packets in the process.

now we can add a second VPN Director rule to send Unbound to our Wireguard interface:
Local IP: 192.168.50.1
Remote IP: <blank>
IFace: wgcX

and now Unbound works via our Wireguard interface whenever wgcX are enabled. if it is disabled, the FW removes the rules and Unbound will work over WAN. we could create duplicates of the last rule if we want foldback to other wireguard interfaces.

There is always a risk that we are affecting other applications on the router that are set to use the LAN ip that communicates externally, but I have not found any issues with it. For example, if anyone uses GUI access from WAN it would probably break that, but that would be bad practice anyway.

An even more reliable way of doing this would be to create a LAN alias interface (much like Diversion is doing with pixelserv) and setup DHCP to not give out that ip. then set Unbound to use that alias interface and create a VPN Director rule for it to the Wireguard interface. Then we could be sure we are not affecting anything else.

Some reference links from the Wireguard Manager days:
https://github.com/ZebMcKayhan/Wire...p-transmission-andor-unbound-to-use-wg-client

https://github.com/ZebMcKayhan/Wire...-andor-unbound-to-use-wg-client-alternate-way

I would personally try to stay away from using fwmark based routing based on the conflict with AIProtect but that is just me. But even though the br0 ip way have been used by many people I have never had any reports of issues I cant guarantee it. but it is easy enough for anyone to play with as long as they adjust the ips in the rules and unbound.conf to fit their system.

 

[CaptainSTX]

Trying to isolate a potential issue with WG clients. Currently using VPMON v1.50 I am getting several notification emails daily that my WG clients are reconnecting. Prior to having notifications setup for WG clients it appeared that my WG clients were rock solid and never restarted. I am trying to determine if this is an issue with Merlin 102.5.0, my VPN provider or I'm just be notified now of something that was always happening and I wasn't aware of. I am using StrongVPN. If others using WG VPN clients and a different VPN provider are having similar issues let me know as this will at least rule out it is an issue caused by the VPN provider. Thanks.

 

[Viktor Jaep]

From what I have seen, the current fix involves fwmark based routing, similar to what was used in X3MRouting and now also in "Domain VPN routing". This method is fragile and conflicts with AIProtect as both are using FWMark and currently there are no bits left unused. The current scheme would have to be expanded with more bits to allow for both OpenVPN and Wireguard selection which further increases the risk for conflict.

Ive remember seeing this function in Unbound Manager and if I remember correctly it sets in unbound.conf:

#outgoing-interface: xxx.xxx.xxx.xxx

to

outgoing-interface: <vpn ipv4>

and then rp_filter to loose (or off) for that interface which FW already does for openVPN but not necessarily for Wireguard. Alternatively use the VPN Director rule to send that interface to wgcX as you already do with ping and speed test.
this would force Unbound to only use that specific interface. but for this to work it has to be set whenever the tunnel starts followed by unbound restart and reset if the tunnel is stopped. otherwise you may loose DNS if the tunnel stops, breaks or fails to start. in order to do this, VPN-start and stop hook files would be used to tell Unbound Manager what to do.

again, it's tricky and potentially fragile.

Im doing it differently. I simply edit unbound.conf (command "vx" inside Unbound manager) and set

outgoing-interface: 192.168.50.1

so, I set it to my LAN ipv4.
This wont really do anything normally. Router would itself typically only use this source address when talking to lan clients and additionally for the few apps that are bound to LAN interface (like the web UI).
The plan is to route this IP to our Wireguard interface of choice, but in order to do that without messing up WebUI for example if are using the killswitch, we make a VPNDirector rule to make sure Router to LAN communication uses Main route table so it wont be affected by any killswitch or whatever is going on in the policy route table:
LocalIP: 192.168.50.1
RemoteIP: 192.168.0.0/16
IFace: WAN

with this rule we will make sure that we are not affecting any local packets in the process.

now we can add a second VPN Director rule to send Unbound to our Wireguard interface:
Local IP: 192.168.50.1
Remote IP: <blank>
IFace: wgcX

and now Unbound works via our Wireguard interface whenever wgcX are enabled. if it is disabled, the FW removes the rules and Unbound will work over WAN. we could create duplicates of the last rule if we want foldback to other wireguard interfaces.

There is always a risk that we are affecting other applications on the router that are set to use the LAN ip that communicates externally, but I have not found any issues with it. For example, if anyone uses GUI access from WAN it would probably break that, but that would be bad practice anyway.

An even more reliable way of doing this would be to create a LAN alias interface (much like Diversion is doing with pixelserv) and setup DHCP to not give out that ip. then set Unbound to use that alias interface and create a VPN Director rule for it to the Wireguard interface. Then we could be sure we are not affecting anything else.

Some reference links from the Wireguard Manager days:
https://github.com/ZebMcKayhan/Wire...p-transmission-andor-unbound-to-use-wg-client

https://github.com/ZebMcKayhan/Wire...-andor-unbound-to-use-wg-client-alternate-way

I would personally try to stay away from using fwmark based routing based on the conflict with AIProtect but that is just me. But even though the br0 ip way have been used by many people I have never had any reports of issues I cant guarantee it. but it is easy enough for anyone to play with as long as they adjust the ips in the rules and unbound.conf to fit their system.

Wow, I really appreciate all the tips with this, @ZebMcKayhan! I'm a big fan of keeping things simple, and was not looking forward to having to deal with the same clunky mechanism currently in use for unbound over VPN.

I like how you're trying things back to your LAN, but I would very much like to also figure how to separate this traffic... like, lets say wgc1 handles all network traffic for your local LAN, but wgc2 handles only unbound DNS lookups for that LAN. Instead of tying things back to your LAN IP, what would the effect be of tying it to your wgc interface IP, like the 10.0.6.x (example) that you would normally get assigned when establishing a connection with a provider?

You've given me lots to read up on and consider! Thanks again!

 

[Viktor Jaep]

Trying to isolate a potential issue with WG clients. Currently using VPMON v1.50 I am getting several notification emails daily that my WG clients are reconnecting. Prior to having notifications setup for WG clients it appeared that my WG clients were rock solid and never restarted. I am trying to determine if this is an issue with Merlin 102.5.0, my VPN provider or I'm just be notified now of something that was always happening and I wasn't aware of. I am using StrongVPN. If others using WG VPN clients and a different VPN provider are having similar issues let me know as this will at least rule out it is an issue caused by the VPN provider. Thanks.

I consider it fairly normal behavior, @CaptainSTX... I see the same thing. Several times throughout the day, either Proton VPN or Nord VPN on my end will exhibit connectivity issues. This is due to the fact that every so often, a network hiccup of some sort is preventing VPNMON from being able to ping 9.9.9.9 (or whatever you have set up), and determines because of that, that your tunnel is most likely down, forcing a reset.

But I'm with you though. I feel that the WG connections have definitely been more stable than VPN, and if you didn't have a tool like VPNMON giving you info like this, you would have never known stuff like this was happening in the background.

I will say that I already have another item on my list that I'm planning on adding that gives the tunnel more time to recover... so instead of seeing a blip like this within 60 seconds and forcing a reset, I was planning on adding a user-configurable number to give you the option to see if it might recover within 2, 3, 5 etc. minutes, and just let it be during that time. Then, if after say 5 minutes, it's still showing signs that it is having trouble connecting, then issue a reset.

 

[ZebMcKayhan]

like how you're trying things back to your LAN, but I would very much like to also figure how to separate this traffic... like, lets say wgc1 handles all network traffic for your local LAN, but wgc2 handles only unbound DNS lookups for that LAN

For the record, the rules I gave would only be effective for Unbound, not the rest of the lan. They could be handled by other rules and sent to other wgc. But it could be issues if you use cidr 192.168.50.0/24 as that also incorperates 192.168.50.1 so it will be up to vpndirector priority. So perhaps not the most flexible way.

what would the effect be of tying it to your wgc interface IP, like the 10.0.6.x (example) that you would normally get assigned when establishing a connection with a provider?

As I wrote, if you also add the rule to send this ip to wgcX it will give your expected effect. But then Unbound would not work if this interface is not up (don't know how it would react if outgoing-interface is set to something that don't exist). So you will have to edit the config file and restart unbound when wgcX is started or stopped. Unless Unbound handles this more gracefully and disregards the outgoing-interface directive when the address is not valid, then it may work.

I'm thinking that it's a pain having to start and stop unbound and changing the config file which is why I prefer to bind it to some other address which we control better.

Perhaps we could create an br0 alias interface with a completally different ip than our LAN, say 10.99.88.77 so we dont need to worry about conflicts with dhcp and set Unbound outgoing-interface to use that ip, always. Then just add a vpndirector rule for that ip to use whatever wgcX we want Unbound to use. I have never created an alias interface with a completally different ip before. I could test this tonight if I have some time.

Edit:
Create the alias interface:

ifconfig br0:UnboundIF 10.99.88.77 netmask 255.255.255.255 up

Create the vpndirector rule for, say, wgc2:

ip rule add from 10.99.88.77 lookup wgc2 prio 11

Test:

admin@RT-AX86U_Pro:/tmp/home/root# ping -I 10.99.88.77 google.com
PING google.com (172.217.21.174) from 10.99.88.77: 56 data bytes
64 bytes from 172.217.21.174: seq=0 ttl=112 time=197.020 ms
64 bytes from 172.217.21.174: seq=1 ttl=112 time=196.958 ms
64 bytes from 172.217.21.174: seq=2 ttl=112 time=196.851 ms

--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 196.851/196.943/197.020 ms

I can see it goes over my wgc2 due to the ping times as my endpoint is on the other side of the world.

I can't set Unbound to use this ip right now as my family are home and I don't want to be kicked out on the Street. Possibly I can test tomorrow.

 

[Viktor Jaep]

As I wrote, if you also add the rule to send this ip to wgcX it will give your expected effect. But then Unbound would not work if this interface is not up (don't know how it would react if outgoing-interface is set to something that don't exist). So you will have to edit the config file and restart unbound when wgcX is started or stopped. Unless Unbound handles this more gracefully and disregards the outgoing-interface directive when the address is not valid, then it may work.

That's why your br0 solution seems so elegant... if the wgc connection goes down, unbound falls back to resolving through the WAN without having to use scripts to bring unbound up/down or edit .conf files. And there doesn't seem to be (or at least I haven't found anything yet) that emulates the same as the openvpn-event file that would fire off whenever there's a major change. I see there's something called PostUp, but would still need to determine if it could be useful.

I'm thinking that it's a pain having to start and stop unbound and changing the config file which is why I prefer to bind it to some other address which we control better.

I'm in complete agreement with that!

Perhaps we could create an br0 alias interface with a completally different ip than our LAN, say 10.99.88.77 so we dont need to worry about conflicts with dhcp and set Unbound outgoing-interface to use that ip, always. Then just add a vpndirector rule for that ip to use whatever wgcX we want Unbound to use. I have never created an alias interface with a completally different ip before. I could test this tonight if I have some time.

Edit:
Create the alias interface:

ifconfig br0:UnboundIF 10.99.88.77 netmask 255.255.255.255 up

Create the vpndirector rule for, say, wgc2:

ip rule add from 10.99.88.77 lookup wgc2 prio 11

Test:

admin@RT-AX86U_Pro:/tmp/home/root# ping -I 10.99.88.77 google.com
PING google.com (172.217.21.174) from 10.99.88.77: 56 data bytes
64 bytes from 172.217.21.174: seq=0 ttl=112 time=197.020 ms
64 bytes from 172.217.21.174: seq=1 ttl=112 time=196.958 ms
64 bytes from 172.217.21.174: seq=2 ttl=112 time=196.851 ms

--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 196.851/196.943/197.020 ms

I can see it goes over my wgc2 due to the ping times as my endpoint is on the other side of the world.

I can't set Unbound to use this ip right now as my family are home and I don't want to be kicked out on the Street. Possibly I can test tomorrow.

That sounds like an interesting approach. I'm in the same boat, and can't bring down the family unit at this point, but should have some time to play this weekend more on this! I'm particularly interested to see how unbound might failback to WAN, or perhaps it won't. Definitely curious now!

 

[ZebMcKayhan]

I'm particularly interested to see how unbound might failback to WAN, or perhaps it won't.

If we actually set up the vpndirector rule in the gui then the fw will take care of adding and removing the rule but if we add it ourselves via "ip rule ..." then it will still be there. But when wgcX are stopped the policy route table gets flushed so routing will continue traverse the rules so we will end up in main route table anyway.

Like this:

admin@RT-AX86U_Pro:/tmp/home/root# ping -c 1 -I  10.99.88.77 google.com
PING google.com (142.250.74.142) from 10.99.88.77: 56 data bytes
64 bytes from 142.250.74.142: seq=0 ttl=112 time=192.538 ms

--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 192.538/192.538/192.538 ms
admin@RT-AX86U_Pro:/tmp/home/root# service "stop_wgc 2"

Done.
admin@RT-AX86U_Pro:/tmp/home/root# ping -c 1 -I  10.99.88.77 google.com
PING google.com (142.250.74.142) from 10.99.88.77: 56 data bytes
64 bytes from 142.250.74.142: seq=0 ttl=113 time=11.035 ms

--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 11.035/11.035/11.035 ms
admin@RT-AX86U_Pro:/tmp/home/root# service "start_wgc 2"

Done.
admin@RT-AX86U_Pro:/tmp/home/root#

So it works as expected!

 

[CaptainSTX]

I consider it fairly normal behavior, @CaptainSTX... I see the same thing. Several times throughout the day, either Proton VPN or Nord VPN on my end will exhibit connectivity issues. This is due to the fact that every so often, a network hiccup of some sort is preventing VPNMON from being able to ping 9.9.9.9 (or whatever you have set up), and determines because of that, that your tunnel is most likely down, forcing a reset.

But I'm with you though. I feel that the WG connections have definitely been more stable than VPN, and if you didn't have a tool like VPNMON giving you info like this, you would have never known stuff like this was happening in the background.

I will say that I already have another item on my list that I'm planning on adding that gives the tunnel more time to recover... so instead of seeing a blip like this within 60 seconds and forcing a reset, I was planning on adding a user-configurable number to give you the option to see if it might recover within 2, 3, 5 etc. minutes, and just let it be during that time. Then, if after say 5 minutes, it's still showing signs that it is having trouble connecting, then issue a reset.

Good to know thanks. In the interim while you see if additional features are needed, I have increased the Ping maximum to 999.