VPNMON Network Resolution Issue (could it be an errant kill switch issue?)

[JTnola]

What could be going on here?

Previously, I ran an OVPN client on my router and administered it using VPNMON-R3. Then something happened that screwed all that up—not sure what, but I do know it happened after installing the latest version. That notwithstanding, I ultimately moved to (1) unmonitor that OVPN slot, (2) use asuswrt-Merlin’s web GUI to turn off the kill switch altogether, (3) then to shut off the OVPN client service altogether, (4) then to uninstall VPNMON-R3 altogether utilizing the script’s own uninstall function …

NOW…. How is it possible that none of the devices connected to my router can successfully access the WAN… BUT the NORD VPN app on my phone *CAN* establish a tunnel and I can surf the web using my home internet — not the cellular internet — BUT ONLY when the VPN app is is turned on??

Is this a kill switch issue? Could some code leftover somewhere be clamping my ability to access the WAN?

ASUSWRT-MERLIN 386.14_2
AC86U

 

[JTnola]

What could be going on here?

Previously, I ran an OVPN client on my router and administered it using VPNMON-R3. Then something happened that screwed all that up—not sure what, but I do know it happened after installing the latest version. That notwithstanding, I ultimately moved to (1) unmonitor that OVPN slot, (2) use asuswrt-Merlin’s web GUI to turn off the kill switch altogether, (3) then to shut off the OVPN client service altogether, (4) then to uninstall VPNMON-R3 altogether utilizing the script’s own uninstall function …

NOW…. How is it possible that none of the devices connected to my router can successfully access the WAN… BUT the NORD VPN app on my phone *CAN* establish a tunnel and I can surf the web using my home internet — not the cellular internet — BUT ONLY when the VPN app is is turned on??

Is this a kill switch issue? Could some code leftover somewhere be clamping my ability to access the WAN?

ASUSWRT-MERLIN 386.14_2
AC86U

 

[JTnola]

Not sure what the deal was, but ultimately all is well again…. With one caveat… I used an earlier backup on which I was still running VPNMON-R3 v. 1.4.1

Eventually, when I’m brave enough to update to the latest version, I’ll let you know how things go…

 

[CaptainSTX]

Not sure what the deal was, but ultimately all is well again…. With one caveat… I used an earlier backup on which I was still running VPNMON-R3 v. 1.4.1

Eventually, when I’m brave enough to update to the latest version, I’ll let you know how things go…

In the future if you need to make changes to a VPN client first go into VPMON and discontinue monitoring that slot then go into the router's GUI make your changes then back into VPMON and resume monitoring the slot. Failure to do so could result in conflicts between the two and could have unknown negative impacts on VPN clients and even your VPN server(s) if you run one.

 

[Viktor Jaep]

You definitely don't want VPNMON running if you're trying to make significant changes to the VPN slot at the same time that it's trying to make changes, like during a reset... or if you've manually stopped the slot, and VPNMON is trying to recover for you by starting it back up. That's really the only time that it would be writing NVRAM values, when it changes servers. It's probably best just to stop VPNMON, make your UI VPN changes, and then start VPNMON back up.

Especially with OVPN... because in order to get a slot configured, you have to upload an actual .conf file that has embedded certificates.

There's no real need to unmonitor a slot first... just stop the script. That does the same thing. That's one less thing you need to re-enable when the script starts back up again. VPNMON really does not have any hooks into the UI/NVRAM that would cause any instability issues. For the most part, it's just watching... unless it needs to switch a server, and in doing so, only changes the necessary NVRAM fields and stops/starts the connection.

There have been no significant changes to the way OVPN operates from v1.4.1 going forward. The big change beyond 1.4.1 was the addition of supporting Wireguard.

I have not played with the built-in Killswitch functionality yet... so I can't comment there.

BACKUPMON certainly is always a good way of getting thing back to square 1 in cases of corruption.

BTW... @JTnola ... I saw your screenshot of exposed ports on your WAN connection. That certainly looks pretty messed up (and scary)! Not sure what would cause that unless some services were enabled that also configured themselves to work across the WAN? Did you enable any new scripts or services around that same time? I'm always checking that same screen in RTRMON whenever I make any major changes to see what the effects were.

 

[CaptainSTX]

In the future if you need to make changes to a VPN client first go into VPMON and discontinue monitoring that slot then go into the router's GUI make your changes then back into VPMON and resume monitoring the slot. Failure to do so could result in conflicts between the two and could have unknown negative impacts on VPN clients and even your VPN server(s) if you run one.

To me it isn't obvious where/how you can disable VPMON totally while on the first set of menus it is more obvious on how to unmonitor a slot M then the code for slot(s) you want disabled.

 

[Viktor Jaep]

To me it isn't obvious where/how you can disable VPMON totally while on the first set of menus it is more obvious on how to unmonitor a slot M then the code for slot(s) you want disabled.

Gotcha. Here's how... While in an SSH session, if you see the script running, just hit CTRL-C

That will terminate the script. This method works for any shell script.

Start it back up by typing vpnmon-r3 ... or if you want it running under the 'screen' utility so it runs in the background, type vpnmon-r3 -screen