External shell script bug - AirVPN Eddie Client 2.8.8

[Opayq 1]

Hi all,

 

I encountered a rather annoying bug. I wrote a shell script that I want to execute every time the VPN tunnel is up. My test script (which does nothing more than echoing text to a test text file) works fine when I set it up under Advanced -> Events -> App Start, App End, Session Start, Session End, VPN Pre, VPN Down but not VPN Up! When I choose to run a script on VPN Up (tested with and without waiting for the script to end) the following happens:

 

Latency tests

Checking authorization

Restart in 3 seconds

Connecting to server

Checking route (request timed out)

 

 

And this goes on and on, the VPN never actually connects.

 

I assume there is a little bug in the VPN Up event.

 

Hopefully this can be fixed in the next version.

 

Best regards

 

 

[Staff 9971]

Thank you very much for the report! Of course, it will be fixed in the next release.

 

Kind regards

[Opayq 1]

Any update on this issue? Does everybody experience this behavior? It's quite inconvenient because I want to use an external DDNS provider. I can only update the ip once the VPN is up.

[Staff 9971]

Hello!

 

If confirmed it will be fixed in the next Eddie version.

 

Work-around: add the "up" directive as a custom directive, in "Custom" field of Eddie "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN Directives" menu/window.

 

Remember to add "script-security 2" as well, in order to tell OpenVPN that your own scripts are authorized.

 

From OpenVPN 2.3.x manual:
 

--up cmd   Run command cmd after successful TUN/TAP device open (pre --user UID change).

cmd consists of a path to script (or executable program), optionally followed by arguments. The path and arguments may be single- or double-quoted and/or escaped using a backslash, and should be separated by one or more spaces.

 

The up command is useful for specifying route commands which route IP traffic destined for private subnets which exist at the other end of the VPN connection into the tunnel.

 

For --dev tun execute as:

cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart ]

For --dev tap execute as:

cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ]

 

See the "Environmental Variables" section below for additional parameters passed as environmental variables.

 

Note that if cmd includes arguments, all OpenVPN-generated arguments will be appended to them to build an argument list with which the executable will be called.

Typically, cmd will run a script to add routes to the tunnel.

Normally the up script is called after the TUN/TAP device is opened. In this context, the last command line parameter passed to the script will be init. If the --up-restart option is also used, the up script will be called for restarts as well. A restart is considered to be a partial reinitialization of OpenVPN where the TUN/TAP instance is preserved (the --persist-tun option will enable such preservation). A restart can be generated by a SIGUSR1 signal, a --ping-restart timeout, or a connection reset when the TCP protocol is enabled with the --proto option. If a restart occurs, and --up-restart has been specified, the up script will be called with restart as the last parameter.

The following standalone example shows how the --up script can be called in both an initialization and restart context. (NOTE: for security reasons, don't run the following example unless UDP port 9999 is blocked by your firewall. Also, the example will run indefinitely, so you should abort with control-c).

openvpn --dev tun --port 9999 --verb 4 --ping-restart 10 --up 'echo up' --down 'echo down' --persist-tun --up-restart

 

Note that OpenVPN also provides the --ifconfig option to automatically ifconfig the TUN device, eliminating the need to define an --up script, unless you also want to configure routes in the --up script.

 

If --ifconfig is also specified, OpenVPN will pass the ifconfig local and remote endpoints on the command line to the --up script so that they can be used to configure routes such as:

route add -net 10.0.0.0 netmask 255.255.255.0 gw $5

 

--up-delay Delay TUN/TAP open and possible --up script execution until after TCP/UDP connection establishment with peer.

In --proto udp mode, this option normally requires the use of --ping to allow connection initiation to be sensed in the absence of tunnel data, since UDP is a "connectionless" protocol.

On Windows, this option will delay the TAP-Win32 media state transitioning to "connected" until connection establishment, i.e. the receipt of the first authenticated packet from the peer.

 

Kind regards

[Opayq 1]

Thanks for the reply. The above mentioned work around successfully executes my script. But for some reason, the DNS check fails. The VPN connection immediately gets disconnected and tries again. This goes on forever. The script simply echoes test to a text file so I don't see how that should interfere with DNS checking.

 

At the moment I found another work around that works for me. In the VPN pre event script I've added a "at" command. For example "at now + 1 min < path/to/text/file.txt" where the text file contains the command to execute. This would run just after the VPN is up. Not the best solution but at least it's working for me.

[Staff 9971]

Thanks for the reply. The above mentioned work around successfully executes my script. But for some reason, the DNS check fails. The VPN connection immediately gets disconnected and tries again. This goes on forever. The script simply echoes test to a text file so I don't see how that should interfere with DNS checking.

 

At the moment I found another work around that works for me. In the VPN pre event script I've added a "at" command. For example "at now + 1 min

 

Hello!

 

Very well.

 

Just as a side note, about the failure you mention, if you're running a Linux system make sure that in the DNS Switch mode combo box (in AirVPN->Preferences->Advanced) you select "Renaming", not "Resolvconf" or "Automatic", in order to prevent any possible conflict between your up directive and the up directive that the client will need to accept DNS push through resolvconf-related script.

 

Kind regards