Remotely DHCP assigned IP - Release the DHCP lease on disconnection

[Isidoro Russo]

Hi all,

I was trial&testing my VPN server (server-bridge on dev tap)  and Tunnelbrick making lots of connections/disconnections. Everything was working ok, I was getting IP, DNS, WINS and search domain from the remote DHCP server (through the VPN) until, suddenly, on the n-th connection I didn't receive anything from the DHCP.  

I was certain I hadn't changed anything on my mac side so I connected (on remote desktop this time) to my remote DHCP server (the one in the office, that wasn't replying anymore) to investigate.

 I found out that for any successful connection I had done with tunnel brick, there was an open lease with an IP assigned (every connection had a different IP). In this way, I had finished the pool of available addresses and the DHCP wasn't able to assign me a new one anymore. I manually terminated the leases and then tunnel brick connected again with no problem.

So I wonder: is there a way to release a DHCP lease when closing a VPN connection? Is it something that has to do with tunnel brick, the openvpn server or the DHCP server itself?

On Windows I think I'd add an ipconfig /release instruction on the disconnection script but on mac I don't know of any equivalent (I am an not used to mac shell).

What do you think?

Thanks a lot,

Ciao

Isidoro

[jkbull...gmail.com]

I'm very sorry that I haven't replied to this earlier; I lost track.

I don't know enough about this to help much, but no one else has responded, so here goes:

 I think it may be a problem with your DNS server. It seems to me that if a device asks for a new IP address again and again, it should be given the same address each time -- based on its MAC address. (Not the Mac IP address -- the MAC address is a unique code given to each Ethernet device).

One thing you could try -- from the network the DNS server is on -- is to get your regular IP address via DHCP from the server, and then go to System Preferences : Advanced : TCP/IP tab, and repeatedly clicking "Renew DHCP Lease". My DHCP server always gives me the same IP address. (This wouldn't involve Tunnelblick.)

If the DNS server gives you a different address each time, that (I think) means it is misconfigured.

If it gives you the same address each time, there could still be a problem if it only does that because it is being released first (because that's the way renewals work), but it might point in the right direction.

[Nick Williams]

I can contribute and say that when I'm on-location where my VPN is hosted, I can click "Renew DHCP Lease" over and over again and get the same IP address. But when I connect via the VPN, every time I reconnect I get a new IP address. I, too, ran out of IP addresses one day when I was testing the configuration.

Jonathan, when I was working on the up/down scripts, I noticed that the TAP interface had already been destroyed by the time the down script ran, which means that we couldn't manually release the DHCP lease in the down script. Is there a pre-down script that runs before the TAP interface is destroyed? If so, we can very easily check if it was configured using DHCP (if `ipconfig getpacket "$dev"` returns ANYTHING on standard out, DHCP was used), and we should be able to fairly easily release the lease in that case (I believe `ipconfig set "$dev" NONE` should do the trick).

Nick

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/tunnelblick-discuss/-/BulMJSCjTqUJ.
To post to this group, send email to tunnelbli...@googlegroups.com.
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.

[Jonathan K. Bullard]

Jonathan, when I was working on the up/down scripts, I noticed that the TAP interface had already been destroyed by the time the down script ran, which means that we couldn't manually release the DHCP lease in the down script. Is there a pre-down script that runs before the TAP interface is destroyed? If so, we can very easily check if it was configured using DHCP (if `ipconfig getpacket "$dev"` returns ANYTHING on standard out, DHCP was used), and we should be able to fairly easily release the lease in that case (I believe `ipconfig set "$dev" NONE` should do the trick).

Ah. That's interesting. Thanks, Nick.

There is no way to hook up a pre-TAP-close script.

But there is an OpenVPN option, --down-pre, that calls the down script before, rather than after, TUN/TAP close.

One potential problem with using it is is that there might be things in the standard down script which would fail if it were called before the TUN/TAP close.

Another is that there may be things the standard down script does which can only be done after the tun/tap close.

Third, I don't see how the down script can find out if it has been called with --down-pre. But maybe it can detect whether or not TUN/TAP has been closed?

If these can potential problems can be dealt with, then maybe the standard down script could be modified to handle itself properly whether or not --down-pre was used.

If the up script could tell OpenVPN to use --down-pre, then it could "force" --down-pre only if DHCP was being pushed from the server, but I don't see how to make that happen.

Or if the down script can work either way, Tunnelblick could always (for the standard script) force --down-pre.

Otherwise, --down-pre could be pushed from the server (or put in the configuration file), and a customized down script could release the lease.

[Nick Williams]

Hmmm. The fact that you can't have a pre-down and post-down script bothers me.

The only attempt I would suggest would be to force pre-down always, but only if we could delay most of the script execution until after the OpenVPN shut down.

So, here's what we could do:

- Script runs BEFORE device shutdown

- DHCP lease released

- Down script continues in background, so that OpenVPN can continue shutting down

- Down script sleeps and monitors process, and only continues to tear down everything else when it would normally run without --down-pre.

So the question is, does OpenVPN normally remove the device, then IMMEDIATELY call the down script (without --down-pre)? Or does it do other things before calling the down script?

If it removes the device and then IMMEDIATELY calls the down script, then with --down-pre we could check the status of the device with `ipconfig getifaddr "$dev"` and that command will return a 0 status code until the device no longer exists, at which point it returns a non-zero status code. Then, once it returns non-zero, we could continue with the rest of the down script and everything else should be the same.

If, however, OpenVPN does other tasks between removing the device and calling the down scripts (without --down-pre), we would need some way to actually monitor when the OpenVPN process dies, and then complete our work after that.

Does this make sense?

N

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

[Jonathan K. Bullard]

Hmmm. The fact that you can't have a pre-down and post-down script bothers me.

Yeah, there are a lot of quirks to OpenVPN like that and, from another discussion, not having any way to override --redirect-gateway (and some other options, like --down-pre) via command-line arguments.

The only attempt I would suggest would be to force pre-down always, but only if we could delay most of the script execution until after the OpenVPN shut down.

So, here's what we could do:

- Script runs BEFORE device shutdown

- DHCP lease released

- Down script continues in background, so that OpenVPN can continue shutting down

- Down script sleeps and monitors process, and only continues to tear down everything else when it would normally run without --down-pre.

So the question is, does OpenVPN normally remove the device, then IMMEDIATELY call the down script (without --down-pre)? Or does it do other things before calling the down script?

If it removes the device and then IMMEDIATELY calls the down script, then with --down-pre we could check the status of the device with `ipconfig getifaddr "$dev"` and that command will return a 0 status code until the device no longer exists, at which point it returns a non-zero status code. Then, once it returns non-zero, we could continue with the rest of the down script and everything else should be the same.

If, however, OpenVPN does other tasks between removing the device and calling the down scripts (without --down-pre), we would need some way to actually monitor when the OpenVPN process dies, and then complete our work after that.

Does this make sense?

That makes sense, but I think it does do some processing -- I think the routing (or un-routing) is done then -- I'll check and make sure.

There's a problem with monitoring to see if the OpenVPN process dies: a reconnection (done by OpenVPN all by itself) runs the down script, and then the up script, gets a connection, and continues -- the process never dies. So we can't rely on the OpenVPN process dying to trigger what we do.

If it's too complicated, don't bother to answer this because I'm just curious: what does the down script do that needs the TUN/TAP device to be closed? In other words, why can't we do all the processing in the down script when it is run with --down-pre?

Could the script could close the TAP connection itself, do the rest of the processing, and then return to OpenVPN? OpenVPN would then get an error (I assume) when it tries to close the TAP device (because it was already closed), but OpenVPN might ignore the error.

Tunnelblick could start all TAP configurations with --down-pre, and all TUN connections without it, if that helps. Tunnelblick knows if it is TUN or TAP because Tunnelblick scans the configuration file to decide whether to load the TUN or the TAP kext.

[Jonathan K. Bullard]

I think nothing is done between closing TAP and running the down script.

Here's the verb 9 log of a TUN (all I have) without -down-pre:

2011-09-02 18:38:32 us=441566 TCP/UDP: Closing socket

2011-09-02 18:38:32 us=441675 /sbin/route delete -net 10.17.0.1 10.17.0.173 255.255.255.255

2011-09-02 18:38:32 us=442363 PKCS#11: __pkcs11h_forkFixup entry pid=10789, activate_slotevent=1

2011-09-02 18:38:32 us=442459 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 10.17.0.1: gateway 10.17.0.173

2011-09-02 18:38:32 us=444250 /sbin/route delete -net 88.191.121.143 192.168.125.1 255.255.255.255

2011-09-02 18:38:32 us=444692 PKCS#11: __pkcs11h_forkFixup entry pid=10790, activate_slotevent=1

2011-09-02 18:38:32 us=444736 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 88.191.121.143: gateway 192.168.125.1

2011-09-02 18:38:32 us=446389 /sbin/route delete -net 0.0.0.0 10.17.0.173 128.0.0.0

2011-09-02 18:38:32 us=446896 PKCS#11: __pkcs11h_forkFixup entry pid=10791, activate_slotevent=1

2011-09-02 18:38:32 us=446968 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 0.0.0.0: gateway 10.17.0.173

2011-09-02 18:38:32 us=448274 /sbin/route delete -net 128.0.0.0 10.17.0.173 128.0.0.0

2011-09-02 18:38:32 us=448758 PKCS#11: __pkcs11h_forkFixup entry pid=10792, activate_slotevent=1

2011-09-02 18:38:32 us=448816 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 128.0.0.0: gateway 10.17.0.173

2011-09-02 18:38:32 us=449833 Closing TUN/TAP interface

2011-09-02 18:38:32 us=450015 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d tun0 1500 1560 10.17.0.174 10.17.0.173 init

2011-09-02 18:38:32 us=450631 PKCS#11: __pkcs11h_forkFixup entry pid=10793, activate_slotevent=1

2011-09-02 18:38:32 us=450702 PKCS#11: __pkcs11h_forkFixup return

2011-09-02 18:38:32 us=521561 PID packet_id_free

2011-09-02 18:38:32 us=521659 SIGTERM[hard,] received, process exiting

And with -down-pre:

2011-09-02 18:37:25 us=501059 TCP/UDP: Closing socket

2011-09-02 18:37:25 us=501165 /sbin/route delete -net 10.17.0.1 10.17.0.173 255.255.255.255

2011-09-02 18:37:25 us=501728 PKCS#11: __pkcs11h_forkFixup entry pid=10655, activate_slotevent=1

2011-09-02 18:37:25 us=501776 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 10.17.0.1: gateway 10.17.0.173

2011-09-02 18:37:25 us=503260 /sbin/route delete -net 88.191.121.143 192.168.125.1 255.255.255.255

2011-09-02 18:37:25 us=503757 PKCS#11: __pkcs11h_forkFixup entry pid=10656, activate_slotevent=1

2011-09-02 18:37:25 us=503818 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 88.191.121.143: gateway 192.168.125.1

2011-09-02 18:37:25 us=505712 /sbin/route delete -net 0.0.0.0 10.17.0.173 128.0.0.0

2011-09-02 18:37:25 us=506231 PKCS#11: __pkcs11h_forkFixup entry pid=10657, activate_slotevent=1

2011-09-02 18:37:25 us=506274 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 0.0.0.0: gateway 10.17.0.173

2011-09-02 18:37:25 us=507391 /sbin/route delete -net 128.0.0.0 10.17.0.173 128.0.0.0

2011-09-02 18:37:25 us=507819 PKCS#11: __pkcs11h_forkFixup entry pid=10658, activate_slotevent=1

2011-09-02 18:37:25 us=507866 PKCS#11: __pkcs11h_forkFixup return

                                        delete net 128.0.0.0: gateway 10.17.0.173

2011-09-02 18:37:25 us=509035 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d tun0 1500 1560 10.17.0.174 10.17.0.173 init

2011-09-02 18:37:25 us=509571 PKCS#11: __pkcs11h_forkFixup entry pid=10659, activate_slotevent=1

2011-09-02 18:37:25 us=509620 PKCS#11: __pkcs11h_forkFixup return

2011-09-02 18:37:25 us=570551 Closing TUN/TAP interface

2011-09-02 18:37:25 us=570702 PID packet_id_free

2011-09-02 18:37:25 us=570752 SIGTERM[hard,] received, process exiting

The "PKCS#11" entries could be a problem, but I'm not sure.

[jkbull...gmail.com]

On Friday, September 2, 2011 11:35:24 AM UTC-4, Nicholas Williams wrote:

I can contribute and say that when I'm on-location where my VPN is hosted, I can click "Renew DHCP Lease" over and over again and get the same IP address. But when I connect via the VPN, every time I reconnect I get a new IP address. I, too, ran out of IP addresses one day when I was testing the configuration.

Jonathan, when I was working on the up/down scripts, I noticed that the TAP interface had already been destroyed by the time the down script ran, which means that we couldn't manually release the DHCP lease in the down script. Is there a pre-down script that runs before the TAP interface is destroyed? If so, we can very easily check if it was configured using DHCP (if `ipconfig getpacket "$dev"` returns ANYTHING on standard out, DHCP was used), and we should be able to fairly easily release the lease in that case (I believe `ipconfig set "$dev" NONE` should do the trick).

Nick

Can anyone confirm that the problem of not releasing the DHCP lease is fixed in 3.3beta02 (2012-03-16) and above when using the standard "Set nameserver" setting and using OpenVPN 2.3alpha1?

That version of OpenVPN uses a new script hook which the down script uses to release the DHCP lease before the TAP device is destroyed. (Or at least it is supposed to do that!)

Note: the VPN gets a new IP address each time a connection is made because OpenVPN uses a random MAC address for the TAP device unless the "--lladdr address" option is used.

Thanks.