What's new

VPNMON VPNMON-R2 v2.0 -Jul 10, 2022- Monitor your VPN connection's Health (Thread locked/closed)

  • 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!

OK. I don't think I used any interface when I tried a manual ping on the router. I think I saw it in the code but it didn't click. However, the behavior I described did happen. Browsing did not work on VPN connected devices but VPNMON showed all was OK.

It happens once in a while but it still is happening. I'll try ping over the VPN tunnel next time it happens.

As for the ipapi.co, I didn't look too much into that and wasn't clear on what it was used for. However, now that I know, I checked and I think I've figured out what the issue is. In the VPN client slot page, the address specified can also be a URL in the field:

Server Address and Port

It doesn't have to be an IP address, as is the case for my situation. That probably is done to handle the VPN provider changing server IP addresses. I looked at the nvram variables and I think the rip and not the addr variable should be used:

vpn_client$1_addr ---> vpn_client$1_rip

I think "rip" probably stands for Remote IP. This seemed to be the public IP address for the slot / active VPN when I had a look. That should solve the Undefined in my case and probably all cases.

PS: I was thinking a little more about this. Maybe this should be a configuration option. For example, you can set the description to anything like "New York - Gaming VPN" and another might be "Chicago - Netflix". It wouldn't be an Exit, though. I have "New York-JFK". This is helpful as the OpenVPN configuration file is named using the airport, JFK. I believe many VPN providers do that. In any case, just another thought...no biggie.

PPS: Another thing I noticed. Now, when using the RIP variable, it displays a city. However, it's not what I was expecting. For example, I see "Ashburn" instead of "Washington, DC". I think Ashburn is a suburb of DC but again, I was thinking it would say Washington DC. Just another observation.

Everyone has suggestions :)
And I appreciate the suggestions, @Kal1975!

So this is actually really interesting... I started looking into that RIP variable, and when I tried to call it, it was actually blank! The Addr variable was giving me an IP. I dove into a bit further, and found an article from 5 years ago where RMerlin mentions that the RIP variable only gets updated when you visit the actual UI in a browser. But then I found out that you can force this variable to populate in NVRAM by running this script: /usr/sbin/gettunnelip.sh.

So I'll change this logic around a bit and will start testing using this variable. It will be interesting to see how long it takes to disappear (if it even does after running this script). I'll continue to monitor the city name situation, but I'm actually in favor of getting the most accurate location of my exit IP, no matter what your vpn provider might be telling you. ;)
 
Everyone has suggestions :)

Don't we all, right? Well, testing RIP didn't last very long. I don't think it's a workable solution. There were 2 issues.

1.) The IP you get from the RIP variable doesn't match the NordVPN exit server, and so when you try to do a Load lookup on that IP, you get 0% back because it's invalid.
2.) The RIP variable didn't seem to get populated immediately, and actually seemed to take some time, which borked up the interface due to the delay.

So as a workaround, I'm using the public IP that I can gather from http://icanhazip.com since that's immediate, and using that to perform a more accurate city lookup. So far so good. ;)
 
I've thrown a beta out there if anyone wants to test any of this new functionality... Here's some of the additions:

  • Crunched the code through shellcheck.net... lots of small changes to formatting based on its suggestions -- thanks @SomeWhereOverTheRainBow
  • Added the uninstall parameter to the list in order to completely uninstall the script -- thanks @andywee
  • If the avgping value = null, then display 0 until it fixes itself the next time around
  • Added the ability to hit enter on items during the config that were asking for values, and adds default values in this case -- thanks @chongnt
  • Added a curl http lookup in addition to ping to validate if traffic remains valid over the vpn tunnel -- thanks @Kal1975
  • Changed the vpncity lookup to use the icanhazip.com external/public ip to help with location accuracy -- thanks @Kal1975
Still on my to-do list, but getting closer...
  • spdMerlin integration that changes which VPN tunnel to run speed tests from when the slots change -- thanks @iTyPsIDg
Beta:
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-1.5b.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

If you need to go back, here's the latest stable release:
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-1.4.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"
 
I've thrown a beta out there if anyone wants to test any of this new functionality... Here's some of the additions:

  • Crunched the code through shellcheck.net... lots of small changes to formatting based on its suggestions -- thanks @SomeWhereOverTheRainBow
  • Added the uninstall parameter to the list in order to completely uninstall the script -- thanks @andywee
  • If the avgping value = null, then display 0 until it fixes itself the next time around
  • Added the ability to hit enter on items during the config that were asking for values, and adds default values in this case -- thanks @chongnt
  • Added a curl http lookup in addition to ping to validate if traffic remains valid over the vpn tunnel -- thanks @Kal1975
  • Changed the vpncity lookup to use the icanhazip.com external/public ip to help with location accuracy -- thanks @Kal1975
Still on my to-do list, but getting closer...
  • spdMerlin integration that changes which VPN tunnel to run speed tests from when the slots change -- thanks @iTyPsIDg
Beta:
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-1.5b.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

If you need to go back, here's the latest stable release:
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-1.4.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"
You are awesome!
 
Another situation happened. I had to reset my modem as my internet connection stopped working. After resetting the modem, everything was back to normal.

During the time the internet connection was down, a couple of errors popped up, which is to be expected. VPNMON was trying to switch to a different VPN client. At the end of step 1 where all the clients are stopped, after the last "Done." message, it displayed:

Code:
[[: 1: unknown operand

It then continued to Step 2 and on. It just kept doing this over and over, as the PING was not working.

I'm not sure if VPNMON can or should do anything about this scenario. Here are some thoughts:
  • check the internet connection at some point in the process.
  • check if the old and/or new VPN tunnel interface is up, at some point.
  • skip processing and go to the 60 second wait immediately if the internet connection is down
So, VPNMON is working as expected. Just thinking of ways to handle different scenarios.

Sometimes, for some reason, just turning my internet connection off and then on restores the internet connection...through the web gui. I'm not sure if this is something that VPNMON should try or if there is some other process / script that does this. Does anyone know of one that checks the internet connection and tries to reset it, without manual intervention?
 
Another situation happened. I had to reset my modem as my internet connection stopped working. After resetting the modem, everything was back to normal.

During the time the internet connection was down, a couple of errors popped up, which is to be expected. VPNMON was trying to switch to a different VPN client. At the end of step 1 where all the clients are stopped, after the last "Done." message, it displayed:

Code:
[[: 1: unknown operand

It then continued to Step 2 and on. It just kept doing this over and over, as the PING was not working.

I'm not sure if VPNMON can or should do anything about this scenario. Here are some thoughts:
  • check the internet connection at some point in the process.
  • check if the old and/or new VPN tunnel interface is up, at some point.
  • skip processing and go to the 60 second wait immediately if the internet connection is down
So, VPNMON is working as expected. Just thinking of ways to handle different scenarios.

Sometimes, for some reason, just turning my internet connection off and then on restores the internet connection...through the web gui. I'm not sure if this is something that VPNMON should try or if there is some other process / script that does this. Does anyone know of one that checks the internet connection and tries to reset it, without manual intervention?
There is a script by Martineau that check WAN interface. It can restart WAN interface or even reboot the router. I haven’t try it as my ISP has been stable. In rare occasion my internet is loss due to ppp connection dropped the router can initiate the ppp connection by itself. Probably can try if these two can work together in this scenario.

 
I've been trying to read up on ways to restart the internet connection. I believe I saw that thread.

I also saw another one that sounded interesting. It was this thread:


with the last post talking about how the router doesn't keep the WAN dhcp lease after something happens to the internet connection. I'm still reviewing, but it may be useful, especially since when I've seen this issue, disabling and re-enabling the WAN connection usually works and I don't have to reboot:


Anyway, that's why I was asking whether or not VPNMON should do anything about it. Maybe just to check if the WAN is up and instead of going through all the steps, just wait...until another process restarts the WAN.
 
Another situation happened. I had to reset my modem as my internet connection stopped working. After resetting the modem, everything was back to normal.

During the time the internet connection was down, a couple of errors popped up, which is to be expected. VPNMON was trying to switch to a different VPN client. At the end of step 1 where all the clients are stopped, after the last "Done." message, it displayed:

Code:
[[: 1: unknown operand

It then continued to Step 2 and on. It just kept doing this over and over, as the PING was not working.

I'm not sure if VPNMON can or should do anything about this scenario. Here are some thoughts:
  • check the internet connection at some point in the process.
  • check if the old and/or new VPN tunnel interface is up, at some point.
  • skip processing and go to the 60 second wait immediately if the internet connection is down
So, VPNMON is working as expected. Just thinking of ways to handle different scenarios.

Sometimes, for some reason, just turning my internet connection off and then on restores the internet connection...through the web gui. I'm not sure if this is something that VPNMON should try or if there is some other process / script that does this. Does anyone know of one that checks the internet connection and tries to reset it, without manual intervention?
The operand error posted above may be an example where simple [ ] should have been used instead of non-posix compliant double [[ ]]. Potentially a shell check issue, but busy box should support it unless it is an advanced wildcard pattern check which busybox sh wont support unlike other variants such as bash, ksh,zsh, and yash. Maybe at the time the operand is parsed the check is not valid yet.
 
Last edited:
The operand error posted above may be an example where simple [ ] should have been used instead of non-posix compliant double [[ ]]. Potentially a shell check issue, but busy box should support it unless it is an advanced wildcard pattern check which busybox sh wont support unlike other variants such as bash, ksh,zsh, and yash. Maybe at the time the operand is parsed the check is not valid yet.
You're exactly right @SomeWhereOverTheRainBow ... I have one double [[ left for a wildcard match, but I think it's erroring out when it doesn't even get the data to do any matches against, because the internet is down.

This is an excellent scenario to build in some more improvement.
Anyway, that's why I was asking whether or not VPNMON should do anything about it. Maybe just to check if the WAN is up and instead of going through all the steps, just wait...until another process restarts the WAN.
This is another great idea, @Kal1975 .... I'll see if I can check for WAN up/down, and have VPNMON-R2 sit on the sideline until it comes back up. I'll start working on this... ;)
 
You're exactly right @SomeWhereOverTheRainBow ... I have one double [[ left for a wildcard match, but I think it's erroring out when it doesn't even get the data to do any matches against, because the internet is down.

This is an excellent scenario to build in some more improvement.

This is another great idea, @Kal1975 .... I'll see if I can check for WAN up/down, and have VPNMON-R2 sit on the sideline until it comes back up. I'll start working on this... ;)
I will venture a look at it and let you know if I come up with an idea.
 
Beta2 (v1.5b2) is out there if anyone wants to test any of this new functionality... Here's some of the additions since v1.5b:

  • Some excellent coding suggestions allowed me to eliminate my last [[ ]] wild card match in this code to attempt to catch an error condition when calling the API to check the city name based on the IP address -- thanks so much @SomeWhereOverTheRainBow
  • Added a WAN connectivity check during the regular loop to see if the WAN is up or down based on an SSL handshake + verification to 8.8.8.8 (over the WAN connection). If this fails, VPNMON-R2 will fall back to a loop, and keep rechecking until the WAN is re-established -- thanks @Kal1975
  • Added some modification to the timing involved in calculating the TX/RX values over the VPN tunnel. Due to the time it takes for the WAN to determine connectivity + the NordVPN Load lookup, I'm timing these functions to add their results to the entire calculation, hopefully to display slightly more accurate stats.
Still on my to-do list, but working with @Jack Yaz on this and getting closer...
  • spdMerlin integration that changes which VPN tunnel to run speed tests from when the slots change -- thanks @iTyPsIDg

Beta2
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-1.5b2.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"

Stable:
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-1.4.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"
 
Last edited:
  • Added a WAN connectivity check during the regular loop to see if the WAN is up or down based on an SSL handshake + verification to 8.8.8.8 (over the WAN connection). If this fails, VPNMON-R2 will fall back to a loop, and keep rechecking until the WAN is re-established -- thanks @Kal1975

Would love your feedback on this, @Kal1975 ... since you seem to experience frequent WAN outages. Let me know how this works out, OK? ;)
 
OK.

I just re-ran the config portion and started it. Saw the Checking VPN Connectivity text.

Will let you know what/if anything comes up. I'm trying to figure out what's going on with my connection. I'll probably be opening a thread to get input. Seems to happen every few days right now, for some reason, although not predictable.

Thanks for the changes. I had the following observations during config, but these are very minor observations:
  • on 4, 5, and 6 enter was not accepted to select the default value. these are when (Yes/No) is displayed.
  • Also, for those (Yes/No), it does not accept Yes or No but it does accept yes and no. suggest to display (yes/no) instead of (Yes/No)
  • suggest repeat/display the value entered or selected by pressing enter. this is mainly for when enter is used as a confirmation of the value being used. OR, at the end, before saying yes for saving config, redisplay all values being used.
  • Also, maybe display an option to start "... -monitor" using screen and then display text to connect using "screen -r vpnmon-r2"...this will help to avoid me having to remember and type all that text :) Ain't procrastination wonderful!
I hadn't switched to the beta as I had made minor changes to the script. The newest beta is running now and I'll let you know. Thanks
 
Will let you know what/if anything comes up. I'm trying to figure out what's going on with my connection. I'll probably be opening a thread to get input. Seems to happen every few days right now, for some reason, although not predictable.
Yeah, you need to get your line looked at, or perhaps it's your modem... ;(

Thanks for the changes. I had the following observations during config, but these are very minor observations:
  • on 4, 5, and 6 enter was not accepted to select the default value. these are when (Yes/No) is displayed.
  • Also, for those (Yes/No), it does not accept Yes or No but it does accept yes and no. suggest to display (yes/no) instead of (Yes/No)
  • suggest repeat/display the value entered or selected by pressing enter. this is mainly for when enter is used as a confirmation of the value being used. OR, at the end, before saying yes for saving config, redisplay all values being used.
I like the fact that people will need to pick a Yes or No... by default I mean, this is probably the way most people will have their setup configured. Also, I don't seem to have any issue with using any of the following to get it to accept the prompt: Y, N, y, n, Yes, No, yes, no, yES, nO... they all seem to work for me. What do you mean when it does not accept "yes" or "no"? If you hit enter, it will literally prompt you "Please answer Yes or No".

I like the idea of displaying the contents of the choices you made for the config before hitting save... I'll get working on that. ;)

  • Also, maybe display an option to start "... -monitor" using screen and then display text to connect using "screen -r vpnmon-r2"...this will help to avoid me having to remember and type all that text :) Ain't procrastination wonderful!

I like that too... hitting that screen command is a PITA, but I've memorized it over time. I've added a "-screen" switch that will launch it with the "screen -dmS sh /jffs/scripts/vpnmon-r2.sh -monitor" command. Thank you!
 
I tried the config again and the Yes/No seemed to work properly. Not sure what was happening when I was trying it...maybe it was just the enter not picking the default value that was listed.

So it's accepting Y, N, Yes, No, yes, no as you've indicated...just not using the default displayed in brackets when you press enter. I can understand you wanting someone to actually pick a Yes or No value, though. It's good either way and like I said, very minor observations.
 
Another situation happened. I had to reset my modem as my internet connection stopped working. After resetting the modem, everything was back to normal.

During the time the internet connection was down, a couple of errors popped up, which is to be expected. VPNMON was trying to switch to a different VPN client. At the end of step 1 where all the clients are stopped, after the last "Done." message, it displayed:

Code:
[[: 1: unknown operand

It then continued to Step 2 and on. It just kept doing this over and over, as the PING was not working.

I'm not sure if VPNMON can or should do anything about this scenario. Here are some thoughts:
  • check the internet connection at some point in the process.
  • check if the old and/or new VPN tunnel interface is up, at some point.
  • skip processing and go to the 60 second wait immediately if the internet connection is down
So, VPNMON is working as expected. Just thinking of ways to handle different scenarios.

Sometimes, for some reason, just turning my internet connection off and then on restores the internet connection...through the web gui. I'm not sure if this is something that VPNMON should try or if there is some other process / script that does this. Does anyone know of one that checks the internet connection and tries to reset it, without manual intervention?
Are you still experiencing any of these issues? Maybe simulate a WAN failure by unplugging the WAN ethernet cable and plug it back in after making observations..
 
So, I disconnected the ethernet cable at the cable modem. I have quite a few observations.

Main observation is that the router does a bunch of things when you disconnect and then reconnect the internet connection.

The good news is that a short while after reconnecting, everything settles down and then goes back to normal.

I'll be posting more details later, but one thing that I saw was that when the VPN IP address was 23.254.112.148, this did not display the city in VPNMON, it showed the IP address. I manually tried it through the terminal and it worked, it returned "Elk Grove Village". So, I'm guessing that something with the spaces messed up the processing.

I was thinking, I've seen New York before so that shouldn't be the case. So I manually switched to the New York VPN client. The result was unexpected. It still showed the old VPN IP address. I restarted VPNMON and then it showed "New York".

These were a couple of items...there are a few more. I'll post more later.
 
I'll be posting more details later, but one thing that I saw was that when the VPN IP address was 23.254.112.148, this did not display the city in VPNMON, it showed the IP address. I manually tried it through the terminal and it worked, it returned "Elk Grove Village". So, I'm guessing that something with the spaces messed up the processing.

So, some of this is by design... if it tries to do an API lookup on an IP address, and it got an error, or a possible "undefined" message back, then it will put its IP address as the exit name. If you're pulling cables, with WAN going up and down, I wouldn't be surprised to see this. And it will only change this city name when VPNMON-R2 starts up from scratch, or after a reset event has occurred. If something changes on the back-end that VPNMON-R2 isn't aware of, it will just happily keep plunking along thinking nothing's changed.

I'll try to find some time this weekend to pull the main WAN and see if I can duplicate any behavior... but as of this last beta, if the WAN is truly down, it should get stuck in a loop indicating such, and retry for a stable WAN connection every 15 seconds or so. After which, it runs a reset to re-establish a VPN connection.
 

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!

Members online

Top