vpnclient1 up / down scripts (openvpn) ac86u help needed

[Butterfly Bones]

As those who see my posts know, I am a totally scripting inept. I can understand what goes on with about 70% of a script, but seem to have a total mental block on grasping syntax. Here is what I want to do.

AC86U current RMerlin 384.11_0, with one openvpn client configured that occasionally drops. The "ping-restart 60" does not work with my current VPN provider. I found the VPNFailover script from Martineau that works, but I have tried various options to start from various jffs scripts, and each has a shortcoming for my use. The one that I think is best since I have only one vpn client in use is at the bottom of the help section of the script. I have used it to define vpnclient1-up and vpnclient-down scripts as shown in that script.

# Script may be initiated by openvpn-event vpnclientX-up ONLY if one VPN Client is ACTIVE at any given time!!!!
#
#       VPN_ID=${dev:4:1}
#       sh /jffs/scripts/VPN_Failover.sh $VPN_ID wait=10 &
#
# and also needs to be terminated by openvpn-event vpnclientX-down
#       rm "/tmp/vpnclient"$VPN_ID"-monitor"
#

vpnclient1-up

#!/bin/sh
VPN_ID=${dev:4:1}
sh /jffs/scripts/VPN_Failover.sh $VPN_ID wait=10 &

vpnclient1-down

#!/bin/sh
rm "/tmp/vpnclient"$VPN_ID"-monitor"

I understand they need to be called from the openvpn-event script, and mine is empty, only has a shebang. I have searched and read many threads and found one that references an openvpn-event template by john9527 (here) and I tried that with a cut and paste (remember I don't grok scripting) and get these errors when I manually start and stop the vpnclient1.

May  8 09:48:23 RT-AC86U-4608 custom_script: Running /jffs/scripts/service-event (args: start vpnclient1)
May  8 09:48:37 RT-AC86U-4608 openvpn-event[28259]: Script not defined for event: vpnclient1-route-up
May  8 09:52:47 RT-AC86U-4608 rc_service: httpds 11045:notify_rc stop_vpnclient1
May  8 09:52:47 RT-AC86U-4608 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)
May  8 09:52:48 RT-AC86U-4608 openvpn-event[29028]: Script not defined for event: vpnclient1-route-pre-down

I found that template linked in a post in a thread that wanted to add iptables routing with a vpn client event, and I do not need routing other than what is done already with the vpn client start and stop. I guess that template does not do what I want.

I have that vpn client configured to start on boot, and strict client routing in the webGUI.

What I need is to call those vpnclient1-up and vpnclient1-down scripts from openvpn-event. Can anyone please help.

Thank you.

 

[Martineau]

I get these errors when I manually start and stop the vpnclient1.

May  8 09:48:23 RT-AC86U-4608 custom_script: Running /jffs/scripts/service-event (args: start vpnclient1)
May  8 09:48:37 RT-AC86U-4608 openvpn-event[28259]: Script not defined for event: vpnclient1-route-up
May  8 09:52:47 RT-AC86U-4608 rc_service: httpds 11045:notify_rc stop_vpnclient1
May  8 09:52:47 RT-AC86U-4608 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)
May  8 09:52:48 RT-AC86U-4608 openvpn-event[29028]: Script not defined for event: vpnclient1-route-pre-down

These messages are informational only, and are produced by @john9527's openvpn-event script you successfully cloned, and whilst you can confirm if a custom trigger script has been executed by checking the contents of the '/tmp/vpnclient1_state' file, I chose to modify the openvpn-event template to explicitly write a message to Syslog when a trigger script is found and being executed:

# Check script state
vpn_script_state=$(cat $vpn_script_log 2>/dev/null)

if [ "$vpn_script_name" = "$vpn_script_state" ]; then
    #======================================================================================Martineau Hack =====================
    #echo "VPN script" $vpn_script_name "already run" | logger -t "$scr_name"
    echo "     ***VPN script" $vpn_script_name "already run" | logger -t "$scr_name"
    #====================================================================================================================
    exit 0
fi

# Execute and log script state
if [[ -f "/jffs/scripts/$vpn_script_name" ]] ; then
    #======================================================================================Martineau Hack =====================
    echo "     Script executing.. for VPN event: "$vpn_script_name | logger -t $scr_name
    #====================================================================================================================
    echo "$vpn_script_name" > $vpn_script_log
    sh /jffs/scripts/$vpn_script_name $*
else
    #======================================================================================Martineau Hack =====================
    #echo "Script not defined for event: "$vpn_script_name | logger -t $scr_name
    echo "     Script not defined for VPN event: "$vpn_script_name | logger -t $scr_name
    #====================================================================================================================
    exit 0
fi

What I need is to call those vpnclient1-up and vpnclient1-down scripts from openvpn-event.

Hopefully both of your custom openvpn-event trigger scripts 'vpnclient1-up/vpnclient1-down' are being automatically executed as desired, but perhaps you may need to include additional 'logger' messages in them to verify that they are beig executed.

NOTE: To correctly terminate 'VPN_Failover.sh', the semaphore file should ideally be deleted in the 'vpnclient1-route-pre-down' trigger.

If you delete the semaphore file in the 'vpnclient1-down' trigger script, then there is a very small possibility that 'VPN_Failover.sh' could restart the VPN Client during the small window when the VPN Client is DOWN but before you physically delete the semaphore.

I'll update the usage comment in the script.

 

[Butterfly Bones]

Thank you for the reply. Unfortunately this is still about 10 stories over my head. I replaced this section of John9527 template with what you posted above in my openvpn-event.

# Check script state/use nvram to save last script run
vpn_script_state=$(nvram get vpn_script_state)
nvram set vpn_script_state="$vpn_script_name"
if [ "$vpn_script_name" = "$vpn_script_state" ]; then
    echo "VPN script" $vpn_script_name "already run" | logger -t "$scr_name"
    exit 0
fi
if [[ -f "/jffs/scripts/$vpn_script_name" ]] ; then
    sh /jffs/scripts/$vpn_script_name $*
else
    echo "Script not defined for event: "$vpn_script_name | logger -t $scr_name
    exit 0
fi
exit 0

Replaced all the vpnclient1 scripts in /jffs/scripts/ and started my vpn client. I find nothing in the syslog that VPN_Failover is running, checking with "ps | grep vpn" only shows the client1 and searching in htop does not show either. The ChkWAN.sh script shows in htop, starting it from /jffs/scripts/wan-start.

I'll wait for your script update on GitHub.

 

[eibgrad]

Hmm, me thinks perhaps the OP is running into the problem I discussed previously.

https://www.snbforums.com/threads/iptables-command-needed-with-openvpn-client.56312/#post-485420

Contrary to popular belief, the up/down events are NOT always triggered by the OpenVPN client. It depends on your configuration. I would dump the underlying OpenVPN client config once its up and running and verify which OpenVPN events are being handled by their respective directives. In my case, I had to move my scripts from up/down to route-up/route-pre-down because the latter were the only events being used by the OpenVPN client.

 

[Martineau]

Contrary to popular belief, the up/down events are NOT always triggered by the OpenVPN client. It depends on your configuration.

I'm sure @RMerlin will gratefully accept a pull request for your proposed fix.

Sadly after all theses years I must be still doing something wrong, as both the UP and ROUTE-PRE-UP trigger scripts (as indeed do both the ROUTE-PRE-DOWN and DOWN scripts) have always fired for me.

'/jffs/scripts/vpnclient1-up' schedules the 'VPN_Failover.sh' script 60 seconds later,
and
'/jffs/scripts/vpnclient1-route-up' executes '/jffs/scripts/WiFiVPN.sh'

Running v384.11

It may be easier to view using a web browser in full screen

i.e. click on the 'Enter full screen" icon

in the bottom right-hand corner of the video window

 

[Martineau]

I'll wait for your script update on GitHub.

The new version of 'VPN_Failover.sh' will simply amend the usage comments which has unfortunately caused your issue.

Replaced all the vpnclient1 scripts in /jffs/scripts/ and started my vpn client. I find nothing in the syslog that VPN_Failover is running, checking with "ps | grep vpn" only shows the client1 and searching in htop does not show either.

First, check if there are issues with the openvpn-event script

grep   "already run"   /opt/var/log/messages

So, abject apologies for the dodgy documentation.
i.e.

./VPN_Failover.sh wait=nn

is not a valid directive for 'VPN_Failover.sh' - see the help.

In my defence, I was in two minds about the desired meaning (in a different script) of 'wait=' vs. 'delay=', so I decided that 'delay=' should imply stalling the initial execution of the script as opposed to 'wait=' which should imply a pause in the script's execution awaiting say the outcome of an action/test condition.

I suggest you try the following scripts (note the quotes around the args, and I recommend the 'delay=' value is twice the interval between checking the status, and if you don't want a round-robin then explicitly exclude the other VPN Clients)

/jffs/scripts/vpnclient1-up

#!/bin/sh
VPN_ID=${dev:4:1}
/jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" "ignore=2,3,4,5" &

EDIT: Just realised that destroying any running instance of 'VPN_Failover.sh' by 'vpnclientX-route-pre-down' will shoot itself in the foot.
I'll have to rethink the logic.

 

[eibgrad]

@Martineau

Just because YOU haven't experienced the problem, doesn't mean it isn't happening. Even after all these years.

Did a little more digging and discovered at least one reason it's not triggering the up/down events in my case (I'm using 384.5 if it matters). If I have Accept DNS Configuration set to Disabled, that's when it seems to NOT include the up/down events in /tmp/etc/openvpn/client1/config.ovpn. Even the updown.sh script disappears from the /tmp/etc/openvpn/client1 directory. As soon as I select anything other than Disabled, the up/down events get added to the config.ovpn file and the updown.sh script reappears.

And now that I think about, that sort of makes sense. After skimming the updown.sh script, the only thing it seems to be doing is things related to reconfiguring and restarting DNSMasq for DNS changes based on that option.

Is that a bug? Or is that the way it's supposed to work?

As I said before, NOT all events are being triggered under all situations. The OpenVPN client is NOT consistent, or at least NOT as consistent as you believe it to be.

 

[L&LD]

@Martineau

Just because YOU haven't experienced the problem, doesn't mean it isn't happening. Even after all these years.

Did a little more digging and discovered at least one reason it's not triggering the up/down events in my case (I'm using 384.5 if it matters). If I have Accept DNS Configuration set to Disabled, that's when it seems to NOT include the up/down events in /tmp/etc/openvpn/client1/config.ovpn. Even the updown.sh script disappears from the /tmp/etc/openvpn/client directory. As soon as I select anything other than Disabled, the up/down events get added to the config.ovpn file and the updown.sh script reappears.

And now that I think about, that sort of makes sense. After skimming the updown.sh script, the only thing it seems to be doing is things related to reconfiguring and restarting DNSMasq for DNS changes based on that option.

Is that a bug? Or is that the way it's supposed to work?

As I said before, NOT all events are being triggered under all situations. The OpenVPN client is NOT consistent, or at least NOT as consistent as you believe it to be.

I can't help with this conversation, it is far above me.

Just wondering though if the 384.5 version of the firmware has anything to do with it? Are the issues fixed or still present in 384.11_0? And, which router are we talking about that has the older firmware installed and exhibits this issue?

 

[eibgrad]

I can't help with this conversation, it is far above me.

Just wondering though if the 384.5 version of the firmware has anything to do with it? Are the issues fixed or still present in 384.11_0? And, which router are we talking about that has the older firmware installed and exhibits this issue?

I'm using an ASUS RT-AC68U. I suppose I could update the firmware and see if anything changes. It's just a lab router I use for testing purposes. But given the fact the updown.sh script is focused on DNS reconfiguration, I have a strong suspicion the situation will remain unchanged. I'm thinking Merlin decided to NOT use the up/down events because they are irrelevant when Accept DNS Configuration is Disabled. There's just no purpose to the events, at least for his purposes. Of course, the user who is writing their own scripts and expecting the up/down events to always be triggered doesn't realize why they aren't, despite everyone telling them they always are triggered.

 

[L&LD]

I'm using an ASUS RT-AC68U. I suppose I could update the firmware and see if anything changes. It's just a lab router I use for testing purposes. But given the fact the updown.sh script is focused on DNS reconfiguration, I have a strong suspicion the situation will remain unchanged. I'm thinking Merlin decided to NOT use the up/down events because they are irrelevant when Accept DNS Configuration is Disabled. There's just no purpose to the events, at least for his purposes. Of course, the user who is writing their own scripts and expecting the up/down events to always be triggered doesn't realize why they aren't, despite everyone telling them they always are triggered.

Again, this is not what I usually deal with. But many things have changed since 384.5. Not all of them will have been documented.

If you do decide to test the latest version, please do a full reset afterward as RMerlin recommends. Thank you for your contributions to the forums here!

 

[eibgrad]

Again, this is not what I usually deal with. But many things have changed since 384.5. Not all of them will have been documented.

If you do decide to test the latest version, please do a full reset afterward as RMerlin recommends. Thank you for your contributions to the forums here!

Thanks for the kind words.

Can't do it immediately, but I'll try this afternoon.

Btw, it's NOT just the up/down events that are inconsistent. The route-up/route-down events on the OpenVPN server are NOT included in current my OpenVPN server config either.

Again, I don't think Merlin is including events unless *he* needs them. And if that happens to correspond w/ your need for these same events to be triggered, everyone is happy. And all appears normal. But when those two worlds collide (Merlin v. the user), you can end up w/ these inconsistencies. And that's going to drive the OpenVPN newb crazy because they'll have no clue why their scripts don't always work.

That's why I ask, is this a bug, or is this by design?

Anyway, we'll see what the situation is once I get updated. In the meantime, it would be *nice* if someone currently using the OpenVPN client w/ a recent build could briefly Disable the Accept DNS Configuration and let us know if they are seeing the same thing.

 

[RMerlin]

Is that a bug? Or is that the way it's supposed to work?

Here is how it's currently implemented in the source code:

Client:
updown.sh is only used if DNS mode is not set to "Ignore" and authentication mode is set to TLS. This is because there was nothing before that in that script for these other modes.

Non-TLS mode will use /jffs/scripts/openvpn-event if it exists.

So for clients, there seems to be an issue where setting DNS to ignore will fail to link the updown event to openvpn-event.


Server:
up/down events are only configured if /jffs/scripts/openvpn-event exists (and linked against it). This was as intended.



While it may not be "consistent", this was not an issue because it was never officially intended for updown.sh to always be used and for end-users to rely on that script. openvpn-event is the proper, supported way to customize up/down events.

The only issue I see after a quick glance at that code (a more extensive review might be needed to dig up the small details) is that clients with DNS mode set to Ignore will not properly use openvpn-event. This should be addressed in 384.12.

 

[RMerlin]

That portion of the code can be found in router/rc/openvpn.c, in the two functions that handle starting clients and servers.

 

[Butterfly Bones]

The new version of 'VPN_Failover.sh' will simply amend the usage comments which has unfortunately caused your issue.

First, check if there are issues with the openvpn-event script

grep   "already run"   /opt/var/log/messages

So, abject apologies for the dodgy documentation.
i.e.

./VPN_Failover.sh wait=nn

is not a valid directive for 'VPN_Failover.sh' - see the help.

In my defence, I was in two minds about the desired meaning (in a different script) of 'wait=' vs. 'delay=', so I decided that 'delay=' should imply stalling the initial execution of the script as opposed to 'wait=' which should imply a pause in the script's execution awaiting say the outcome of an action/test condition.

I suggest you try the following scripts (note the quotes around the args, and I recommend the 'delay=' value is twice the interval between checking the status, and if you don't want a round-robin then explicitly exclude the other VPN Clients)

/jffs/scripts/vpnclient1-up

#!/bin/sh
VPN_ID=${dev:4:1}
/jffs/scripts/VPN_Failover.sh "$VPN_ID" "delay=60" "ignore=2,3,4,5" &

EDIT: Just realised that destroying any running instance of 'VPN_Failover.sh' by 'vpnclientX-route-pre-down' will shoot itself in the foot.
I'll have to rethink the logic.

No need to apologize, I like troubleshooting things, I just have so much trouble grasping scripting logic. Other logic is easy for me. I'm glad I found something that will improve the script for all who use it,

I understand the "wait" vs "delay" logic, and I see the disparity in the script now that you point it out. With my stumbling through scripting I did not look at that closely. On positive side I do learn through all my trials and tribulations. I'm more than willing to test things to make them better.

With the need to redo the logic of the "vpnclinetX-route-pre-down" I'll wait to see what you find. I have VPN_Failover.sh running in an SSH terminal for now that seems to work. I tried many variations in a cron job earlier and for one reason or another, my VPN would drop, and this script did not bring it back up. I guessed I did not have the correct "logic" in my command line switches, hence my quest to pursue the vpnclinetX-up/down scripts.

Thank you for looking into this, I appreciate the responses.

 

[eibgrad]

That portion of the code can be found in router/rc/openvpn.c, in the two functions that handle starting clients and servers.

FWIW, I have TLS control channel security set to Disabled. I don't normally use tls-auth or tls-crypt. And certainly not every OpenVPN provider requires it. Based on the code in /rc/openvpn.c, that would *appear* to be the problem. I'm not sure why it's conditional in the first place.

EDIT: I take that back. It won't add the up/down events only if TLS *is* the mode. Still not clear why that's an exception. So that's seems to be a red herring.

 

[Butterfly Bones]

If I have Accept DNS Configuration set to Disabled, that's when it seems to NOT include the up/down events in /tmp/etc/openvpn/client1/config.ovpn. Even the updown.sh script disappears from the /tmp/etc/openvpn/client1 directory. As soon as I select anything other than Disabled, the up/down events get added to the config.ovpn file and the updown.sh script reappears.

I have my Accept DNS Configuration set to Disabled as well, using router firmware integrated DoT / stubby with Cloudflare and now current 384.11-0 released yesterday. I see now that RMerlin just clarified that, so I will leave it set to Disabled and wait to see what Martieau comes up with.

 

[eibgrad]

I have my Accept DNS Configuration set to Disabled as well, using router firmware integrated DoT / stubby with Cloudflare and now current 384.11-0 released yesterday. I see now that RMerlin just clarified that, so I will leave it set to Disabled and wait to see what Martieau comes up with.

What's your TLS control channel security setting?

 

[Butterfly Bones]

What's your TLS control channel security setting?

It is set to Disabled. I import an ovpn file from my VPN provide and only change Policy Rules to Strict and and add to the Custom Configuration. I only loose about 5-10 MB/s with my VPN with this provider, even though the server is 250 miles away.

 

[eibgrad]

Ok, updated to 384.11 (beta) and got the same results.

Again, I have Accept DNS Configuration set to Disabled. And I'm NOT using TLS mode. I created the simplest ovenvpn-event script imaginable. It just dumps whatever events it happens to see to the syslog.

#!/bin/sh
echo $script_type | logger -t $(basename $0)[$$]
exit 0

I turn the OpenVPN client ON, then OFF, and get the following output in the syslog.

https://pastebin.com/ktEq7tzS (had to use PasteBin, wouldn't let me post the syslog directly)

As you can see, NO up/down events. Just route-up/route-pre-down.

 

[Butterfly Bones]

Ok, updated to 384.11 (beta) and got the same results.

Again, I have Accept DNS Configuration set to Disabled. And I'm NOT using TLS mode. I created the simplest ovenvpn-event script imaginable. It just dumps whatever events it happens to see to the syslog.

#!/bin/sh
echo $script_type | logger -t $(basename $0)[$$]
exit 0

I turn the OpenVPN client ON, then OFF, and get the following output in the syslog.

https://pastebin.com/ktEq7tzS (had to use PasteBin, wouldn't let me post the syslog directly)

As you can see, NO up/down events. Just route-up/route-pre-down.

I got an email notification for a post from you earlier, it is still being held in the @#$%& Cloudflare moderation queue. I get that often too with all my code tags.

I just duplicated your test with that openvpn-event script, start and stop.

May  9 12:23:49 RT-AC86U-4608 rc_service: httpds 3184:notify_rc start_vpnclient1
May  9 12:23:49 RT-AC86U-4608 custom_script: Running /jffs/scripts/service-event (args: start vpnclient1)
May  9 12:23:58 RT-AC86U-4608 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1553 10.200.0.6 10.200.0.5)
May  9 12:23:58 RT-AC86U-4608 openvpn-event[7112]: route-up
May  9 12:24:08 RT-AC86U-4608 rc_service: httpds 3184:notify_rc stop_vpnclient1
May  9 12:24:08 RT-AC86U-4608 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)
May  9 12:24:08 RT-AC86U-4608 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1553 10.200.0.6 10.200.0.5 init)
May  9 12:24:08 RT-AC86U-4608 openvpn-event[7218]: route-pre-down

I have "Accept DNS Configuration" Disabled and "TLS control channel security" Disabled.

My ovpn file import sets Accept DNS Configuration to "Relaxed" and I change that to Disabled. The TLS control channel is set to Disabled by the ovpn file.

edit - I just realized that syslog-ng scrapes out all the "openvpn-client1" messages.