2

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

  • A dumb idea: what happens if you set a script for client-disconnect as well? Does openvpn really thinks the client got disconnected? Another idea of the same class: could you enable management interface on the server, 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? – kostix Nov 13 '15 at 18:14
  • By the way, I'd drop that system bit: it's not needed in your case. – kostix Nov 13 '15 at 18:15
  • 1
    I'm asking because 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. – kostix Nov 13 '15 at 18:23
  • Looks like you are spot on kostix. I added explicit-exit-notify [n] to the client, and now its working as expected. If you add your comment as an answer, Ill accept it. Thanks again! – GeoSword Nov 13 '15 at 18:38
  • Glad it helped! – kostix Nov 13 '15 at 19:41
2

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.

| improve this answer | |
0

to get another "testing" , use option log append to file , in your case /etc/openvpn/scripts/test. the problem that first testing is overrite by second. so you don`t see it, but you get it

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.