OpenVPN and client-connect scripts

debian-wheezyopenvpn

I have an OpenVPN server (2.3.2) on Debian Wheezy operating in bridged mode. Everything's working fine in terms of the client connecting and getting access to the network(s) it needs.
Im trying to add a few bells and whistles through use of the client-connect option. This is the pertinent part of the openvpn config file:

script-security 3 system
client-connect /etc/openvpn/scripts/clientconnect.sh

In an attempt to check that the script is actually run, clientconnect.sh
consists of this:

#!/bin/bash
echo "testing">>/etc/openvpn/scripts/test
exit 0

Simple enough.

If I run the script from the command line, as expected "testing" is appended
to /etc/openvpn/scripts/test every time, and 0 returned.

When I connect from my client, then I get a "testing" in
/etc/openvpn/scripts/test. Great!

But when I disconnect, and connect again, I don't get another "testing"

So, to check its actually being run I changed the exit value in clientconnect.sh to 1

sure enough, every attempt to connect from the client then failed because
the script returns a non 0 value.

Why does it look like the script isn't being run?

BTW, if I restart the openvpn service on the server then I get "testing" once
more, but again, nothing is written on subsequent connections.

Any pointers / Help / Mystic Incantations are all gratefully received!
Dylan

Best Answer

OpenVPN is made to be very resilient to network outages (and it really excells at it), so unless you have something like explicit-exit-notify [n] in your client's configuration, disconnecting that client will look like a network outage to the server.

Then, depending on how you did configue timeouts/keepalives etc, it could be a hefly amount of time before the server decides the client is really gone. You might just have not reached this condition in your tests.

A way to verify this is to enable the management interface in your server then do telnet localhost 1194 there and verify the client is really disconnected — after disconnecting on the client side — by executing the "status" command and inspecting its output.

Another, more low-tech, approach to testing this is hooking a script to the client-disconnect event and see whether it runs when the client disconnects.

Related Topic