VPNMON VPNMON-R2 v2.52 -Mar 27, 2023- Monitor your VPN connection's Health (Thread locked/closed)
- Thread starter Viktor Jaep
- Start date
See some exception that I detected with v2.32, I am not able to go to screen mode, I am only able to enter monitor mode with warning that screen is running
Code:
STATUS:
VPNMON-R2 is currently in a NORMAL state...
Last known VPN Client slot used: 5
pristup@RT-AX86U-3E18:/tmp/home/root#
Code:
Connecting to existing VPNMON-R2 v2.32 SCREEN session...
IMPORTANT:
In order to keep VPNMON-R2 running in the background,
properly exit the SCREEN session by using: CTRL-A + D
Switching to the SCREEN session in T-5 sec...
Attaching from inside of screen?
pristup@RT-AX86U-3E18:/tmp/home/root#
Viktor Jaep
Part of the Furniture
To start VPNMON-R2 in screen mode, simply type:
Code:
vpnmon-r2 -screenIf you already have VPNMON-R2 running in a screen session, to connect to it, simply type:
Code:
vpnmon-r2 -screenWhen I type
I get following "error"
And I can see the session is running, logs are being created
I was not able to connect to session, I had to reset the router, now it works...
I get following "error"
Code:
Connecting to existing VPNMON-R2 v2.32 SCREEN session...
IMPORTANT:
In order to keep VPNMON-R2 running in the background,
properly exit the SCREEN session by using: CTRL-A + D
Switching to the SCREEN session in T-5 sec...
Attaching from inside of screen?
pristup@RT-AX86U-3E18:/tmp/home/root#And I can see the session is running, logs are being created
Code:
Tue Oct 18 20:09:23 CEST 2022 - VPNMON-R2 ----------> STATUS: NORMAL -- SLOT: 5
Tue Oct 18 20:09:44 CEST 2022 - VPNMON-R2 ----------> STATUS: NORMAL -- SLOT: 5
Tue Oct 18 20:19:43 CEST 2022 - VPNMON-R2 ----------> STATUS: NORMAL -- SLOT: 5
Tue Oct 18 20:23:07 CEST 2022 - VPNMON-R2 - API call made to update WAN0 city to Boskovice
Tue Oct 18 20:23:08 CEST 2022 - VPNMON-R2 - API call made to update VPN city to PragueI was not able to connect to session, I had to reset the router, now it works...
Last edited:
Viktor Jaep
Part of the Furniture
Somehow you are trying to attach to a screen session from within a screen session... start all over. Kill all your screens. Do a "screen -ls" and make sure all connections have been killed. Then start over with a "vpnmon-r2 -screen"
Suggest to name the connection which failed i.e. WAN or VPNX
Add command to your guide / initial readme, it will help many people like helped me
Question/suggestion, how is the ping counted for the VPNX tunnel ? Would you consider running a ping test every example 10s and averaging the result before deciding to reset/select the VPN server ?
Code:
Wed Oct 19 10:22:07 CEST 2022 - VPNMON-R2 ----------> ERROR: Connection failed - Executing VPN ResetAdd command to your guide / initial readme, it will help many people like helped me
Code:
screen -lsQuestion/suggestion, how is the ping counted for the VPNX tunnel ? Would you consider running a ping test every example 10s and averaging the result before deciding to reset/select the VPN server ?
Viktor Jaep
Part of the Furniture
Not a problem - added to my list!
I'll add this to my instructions... there's lots you can do with screen - hit "screen -h" to see available options. Or alternatively, tmux... which is a similar type of tool.
Each interval, each VPN client slot is pinged... if it's not connected, it's done from the WAN, if it's a connected tunnel, then it's pinged through the tunnel. This is done 1x each interval. In the interest of time/speed, it's done 1x as the screen redraws. At this point it's not entirely feasible to average a ping every 10 seconds. When using the "Lowest Ping" method, the whole reason why I included the # of chances it gets before a reset is exactly for this reason... so that it has a good 5 minutes to determine whether a vpn client is truly the fastest or not, and then determines if it needs to switch if it's consistently slower.
Last edited:
Right, so another combined proposal
an option where you combine lowest ping with reset i.e. keep averaging the ping (same slots, same IP) until there is hit in "Minimum PING Before Reset" ?Today, I have been doing some additional tests, this might (not) be related to VPNMON (not sure exactly how the reset is performed considering kill switch).
I have experienced few times WAN IP exposure/leakage for the client in VPN tunnel during reset and all the 5 slots has the kill switch option turned on!
Here is the command I executed every 3s and also based on some other events:
Logged actions:
Detected WAN IP (public) in device in VPN tunnel at time:
So assuming, during the reset, there is WAN IP leakage/exposure even with kill switch on. There could be few seconds shift up/down due to some routines running in MQTT messaging but the IP leakage was detected for 100%.
Have you experience this behaviour or test this scenarios ?
I have experienced few times WAN IP exposure/leakage for the client in VPN tunnel during reset and all the 5 slots has the kill switch option turned on!
Here is the command I executed every 3s and also based on some other events:
Code:
p@RT-AX86U-3E18:/tmp/home/root# curl 'https://nordvpn.com/wp-admin/admin-ajax.php?action=get_user_info_data'Logged actions:
Code:
Wed Oct 19 18:46:41 CEST 2022 - VPNMON-R2 ----------> WARNING: AVG PING across VPN tunnel > 100 ms - Executing VPN Reset
Wed Oct 19 18:46:41 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Wed Oct 19 18:46:51 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Wed Oct 19 18:47:12 CEST 2022 - VPNMON-R2 - Refreshed VPN Slots 1 - 5 from 5 Recommended NordVPN Server Locations
Wed Oct 19 18:47:13 CEST 2022 - VPNMON-R2 - Randomly selected VPN5 Client ON
Wed Oct 19 18:47:17 CEST 2022 - VPNMON-R2 - VPN Reset Finished
Wed Oct 19 18:47:19 CEST 2022 - VPNMON-R2 - Trimmed the log file down to 1000 lines
Wed Oct 19 18:47:19 CEST 2022 - VPNMON-R2 - Resuming normal operations
Wed Oct 19 18:47:31 CEST 2022 - VPNMON-R2 - API call made to update WAN0 city to Boskovice
Wed Oct 19 18:47:32 CEST 2022 - VPNMON-R2 - API call made to update VPN city to PragueDetected WAN IP (public) in device in VPN tunnel at time:
Code:
last_updated: '2022-10-19T18:47:01.028432+00:00'So assuming, during the reset, there is WAN IP leakage/exposure even with kill switch on. There could be few seconds shift up/down due to some routines running in MQTT messaging but the IP leakage was detected for 100%.
Have you experience this behaviour or test this scenarios ?
Viktor Jaep
Part of the Furniture
No, but I have learned recently that the killswitch doesn't actually function correctly unless the VPN connection actually fails... This was a graceful reset... You can read more about it here: https://www.snbforums.com/threads/kill-switch-doesnt-work.74948/
,,, and @eibgrad built a nifty little firewall-based killswitch script that you might be interested in running.
Last edited:
Viktor Jaep
Part of the Furniture
This could be interesting... will consider!Right, so another combined proposal
Hi @Viktor Jaep, I've just updated to the latest version (2.32) and I'm seeing this message when I load VPNMON
after a reboot of the router, the message now looks like this:
Any ideas? The logs don't contain any other info
after a reboot of the router, the message now looks like this:
Any ideas? The logs don't contain any other info
Viktor Jaep
Part of the Furniture
Hey @TITAN ... that's pretty major!
Can you open up a command SSH prompt, and just type:
Code:
sleep 2It should sit there for 2 seconds, and come right back to the prompt?
If it's not found, then there might be other stuff going on... you should check under your "/bin" folder, and see if sleep is still listed there?
Have you changed anything with entware recently, or perhaps installed/uninstalled other tools using the "opkg" command?
ComputerSteve
Senior Member
I will say I notice the same thing with the kill switch. I notice that if I use @eibgrad script found here https://www.snbforums.com/threads/kill-switch-doesnt-work.74948/#post-715885 x3mrouting doesn't work !!
Once the client reactivates the ipset rules don't take place. The vpn to wan bypasses that x3mrouting are supposed to have just stop once the client reactivates. So if you use x3mrouting I don't recommend using this script until a solution is created.
Viktor Jaep
Part of the Furniture
If that's the only thing missing/malfunctioning, it looks like you can reinstall this tool using this command. I've never tried this before, but it should work?
Code:
opkg install coreutils-sleepHey @TITAN ... that's pretty major!
Can you open up a command SSH prompt, and just type:
Code:sleep 2
It should sit there for 2 seconds, and come right back to the prompt?
If it's not found, then there might be other stuff going on... you should check under your "/bin" folder, and see if sleep is still listed there?
Have you changed anything with entware recently, or perhaps installed/uninstalled other tools using the "opkg" command?
Yes, that worked, no issues, and sleep is there
I haven't changed anything, in fact the last time I logged into the router was to update VPNMON
I just ran an update in AMTM, and reboot, but the issue still persists... strange
UPDATE:
I had a poke through the code, and noticed line 4247 is the only instance of "Sleep" that is capitalised. I changed this to lower case, and viola, that seems to have fixed it!
in references to the messages I'm receiving, line 55 doesn't even call sleep
and neither does line 4294
Last edited:
Viktor Jaep
Part of the Furniture
Well that is certainly whacky. My router doesn't complain about any of this. I've fixed the "Sleep" incase there is a case sensitive issue going on here with your router, and technically, it should be "sleep". But no idea about the line 55 or 4294 issues. Got to wonder if something more is going on than just this...Yes, that worked, no issues, and sleep is there
View attachment 44913
I haven't changed anything, in fact the last time I logged into the router was to update VPNMON
I just ran an update in AMTM, and reboot, but the issue still persists... strange
UPDATE:
I had a poke through the code, and noticed line 4247 is the only instance of "Sleep" that is capitalised. I changed this to lower case, and viola, that seems to have fixed it!
in references to the messages I'm receiving, line 55 doesn't even call sleep
and neither does line 4294
EDIT: and to follow-up, are you still seeing the same "Sleep: not found" error messages?
Indeed! I wonder if in a previous version it was lower-case?
Anyway, to answer your question, when I made the change on line 4247, I no longer got the "Sleep: not found" message.
I've installed the beta you've sent me and that also works fine.
For completeness/clarity I did not re-install the sleep package.
Viktor Jaep
Part of the Furniture
Added more requests made by you - thanks for your involvement! Enjoy v2.35!
What's new?
v2.35 - (October 21, 2022)
- ADDED: Another commandline parameter "vpnmon-r2 -stop", based on a suggestion from our own @Stephen Harrington! This parameter, much like -pause, will cause VPNMON-R2 to retreat to a loop waiting for a -resume command. The difference here is that unlike with -pause, the -stop command will kill all VPN connections, and will re-establish the VPN once resumed.
- ADDED: Another -config menu item #14 - "Allow WAN1 VPN Connections?". This item determines if you want to allow VPN connections across your WAN1 connection in Dual-WAN situations where you have failed over from your primary WAN connection. In the case of WAN1 connections, these are typically USB devices with limited bandwidth and cost, thus trying to limit the amount of traffic going over these devices. If this option is set, and WAN fails over to WAN1, VPNMON-R2 will kill all VPN connections, loop and wait for WAN0 to become active again before connecting back to your VPN provider. Thanks to @Stephen Harrington for the great suggestion!
- CHANGED: Some of the feedback you receive when VPN resets, to include more granular information about VPN slots or PING values on screen and in the logs. Thanks to @salvo for noting this!
- CHANGED: Fixed some of the text indents across the board to give it a more uniform look/feel.
- FIXED: There was a sleep variable incorrectly misnamed (as "Sleep"), and corrected this in order to prevent any possible "Sleep: Not Found" errors that may pop up as a result. Thanks to @TITAN for finding this mistake!
Download link (or update directly from within AMTM)
Significant Screenshots:
Added new option #14 to determine if you want VPN connections running over WAN1 during dual-wan failover situations:
What's new?
v2.35 - (October 21, 2022)
- ADDED: Another commandline parameter "vpnmon-r2 -stop", based on a suggestion from our own @Stephen Harrington! This parameter, much like -pause, will cause VPNMON-R2 to retreat to a loop waiting for a -resume command. The difference here is that unlike with -pause, the -stop command will kill all VPN connections, and will re-establish the VPN once resumed.
- ADDED: Another -config menu item #14 - "Allow WAN1 VPN Connections?". This item determines if you want to allow VPN connections across your WAN1 connection in Dual-WAN situations where you have failed over from your primary WAN connection. In the case of WAN1 connections, these are typically USB devices with limited bandwidth and cost, thus trying to limit the amount of traffic going over these devices. If this option is set, and WAN fails over to WAN1, VPNMON-R2 will kill all VPN connections, loop and wait for WAN0 to become active again before connecting back to your VPN provider. Thanks to @Stephen Harrington for the great suggestion!
- CHANGED: Some of the feedback you receive when VPN resets, to include more granular information about VPN slots or PING values on screen and in the logs. Thanks to @salvo for noting this!
- CHANGED: Fixed some of the text indents across the board to give it a more uniform look/feel.
- FIXED: There was a sleep variable incorrectly misnamed (as "Sleep"), and corrected this in order to prevent any possible "Sleep: Not Found" errors that may pop up as a result. Thanks to @TITAN for finding this mistake!
Download link (or update directly from within AMTM)
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.35.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.shSignificant Screenshots:
Added new option #14 to determine if you want VPN connections running over WAN1 during dual-wan failover situations:
Stephen Harrington
Very Senior Member
@Viktor Jaep, just testing the manual use of the "-stop / -resume" combo, it would appear (maybe?) that "-resume" always eventually does effectively a "-reset" as a way of getting the VPN running again. Or maybe that's not right and I've just been unlucky? Would a possible improvement be that a "-resume", in the first instance, just re-starts the last VPN client slot that was in use with last used config and endpoint, and then if that doesn't work, goes on to do a "-reset" at the next attempt perhaps?
Similar threads
Similar threads
Similar threads
-
(Not specifically) VPNMON-R3 1.11 failure domino effect- Started by Ripshod
- Replies: 20
-
VPNMON VPNMON-R3 Custom Server List Generation Tutorials and Examples
- Started by Viktor Jaep
- Replies: 63
-
VPNMON VPNMON-R3 - Early, early alpha discussion, progress & screenshots
- Started by Viktor Jaep
- Replies: 17