# openvpn client stops when server is restarted



## dvl@ (Jun 24, 2014)

All systems are running FreeBSD 9.2 with OpenVPN 2.3. When I restart my OpenVPN server, OpenVPN on the clients dies.  Ironically enough, when I search for 'freebsd openvpn Cannot allocate TUN/TAP dev dynamically' (as found below), I find my original post on OpenVPN: http://www.freebsddiary.org/openvpn.php.

Following my own advice, I checked /boot/loader.conf and indeed it contains 
	
	



```
if_tap_load="YES"
```

Here is what I see on one client:


```
Jun 24 21:02:33 nyi openvpn[2501]: [bast.example.org] Inactivity timeout (--ping-restart), restarting
Jun 24 21:02:33 nyi openvpn[2501]: SIGUSR1[soft,ping-restart] received, process restarting
Jun 24 21:02:35 nyi openvpn[2501]: UDPv4 link local: [undef]
Jun 24 21:02:35 nyi openvpn[2501]: UDPv4 link remote: [AF_INET]10.52.41.15:1194
Jun 24 21:02:36 nyi openvpn[2501]: [bast.example.org] Peer Connection Initiated with [AF_INET]10.52.41.15:1194
Jun 24 21:02:38 nyi openvpn[2501]: Preserving previous TUN/TAP instance: tun0
Jun 24 21:02:38 nyi openvpn[2501]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Jun 24 21:02:38 nyi openvpn[2501]: ERROR: FreeBSD route delete command failed: external program exited with error status: 77
Jun 24 21:02:38 nyi last message repeated 2 times
Jun 24 21:02:38 nyi openvpn[2501]: /sbin/ifconfig tun0 destroy
Jun 24 21:02:38 nyi kernel: tun0: link state changed to DOWN
Jun 24 21:02:38 nyi openvpn[2501]: FreeBSD 'destroy tun interface' failed (non-critical): external program exited with error status: 1
Jun 24 21:02:39 nyi openvpn[2501]: Cannot allocate TUN/TAP dev dynamically
Jun 24 21:02:39 nyi openvpn[2501]: Exiting due to fatal error
```

I'm not sure why.

The client configuration is:


```
local 10.233.228.194
client
dev tun
proto udp
remote example.no-ip.org 1194
resolv-retry infinite
#nobind
user  openvpn
group openvpn
persist-key
persist-tun
pull
ns-cert-type server
tls-auth /usr/local/etc/openvpn/keys/ta.key 1
ca       /usr/local/etc/openvpn/keys/ca.crt
cert     /usr/local/etc/openvpn/keys/client.crt
key      /usr/local/etc/openvpn/keys/client.key
comp-lzo
verb 1
verb 4
```


----------



## junovitch@ (Jun 25, 2014)

These lines before the issue you noted catch my eye.

```
Jun 24 21:02:38 nyi openvpn[2501]: Preserving previous TUN/TAP instance: tun0
Jun 24 21:02:38 nyi openvpn[2501]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
```

A search for information regarding that and the persist options lead to this http://openvpn.net/archive/openvpn-users/2004-10/msg00419.html which suggest it may be worth checking that you are using the --ifconfig-pool-persist server side to make sure that it sends the same address back to the client and avoids that second log entry that I mentioned.

It may be worth it to test running the client as root to see what happens when the exact same server side issues happen.  If the logs show it closing the tunnel and re-opening it, which it can because it's root, it would be worth looking into what is preventing the persist-key and persist-tun options from working as desired.


----------



## dvl@ (Jun 25, 2014)

Short answer: that seems to have done it. Thank you.

I was skeptical, because I'm using ccd.

For completeness, here is the server configuration. Of note is the `client-config-dir` directive.  At the end of this post is the ccd for the client above.


```
port 1194
proto udp
dev tun
ca                /usr/local/etc/openvpn/keys/ca.crt
cert              /usr/local/etc/openvpn/keys/bast.example.org.crt
key               /usr/local/etc/openvpn/keys/bast.example.org.key
dh                /usr/local/etc/openvpn/keys/dh1024.pem
crl-verify        /usr/local/etc/openvpn/keys/crl.pem
client-config-dir /usr/local/etc/openvpn/ccd
tls-auth          /usr/local/etc/openvpn/keys/ta.key 0

server 10.8.1.0 255.255.255.0

route 10.80.0.0 255.255.255.0         # zuul
push "route 10.80.0.0 255.255.255.0"  # zuul

route 10.70.0.0 255.255.255.0         # tallboy
push "route 10.70.0.0 255.255.255.0"  # tallboy

keepalive 10 120
client-to-client
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
verb 1
verb 4
replay-window 64 60

push "route 10.55.0.0 255.255.255.0"

script-security 3 system
learn-address /usr/local/openvpn/learn-address
```

The ccd entry for the client in question:


```
# cat ccd/nyi.unixathome.org 
ifconfig-push nyi-vpn.example.org nyi-vpn-endpoint.example.org
```

And the host names in question:


```
# host nyi-vpn.unixathome.org
nyi-vpn.unixathome.org has address 10.8.1.20
# host nyi-vpn-endpoint.unixathome.org
nyi-vpn-endpoint.unixathome.org has address 10.8.1.21
```

After adding this directive, I restarted the server:


```
ifconfig-pool-persist   /var/db/openvpn/ifconfig-pool
```

Here are the log entries for the client in question:


```
Jun 25 04:06:44 nyi openvpn[30456]: [bast.example.org] Inactivity timeout (--ping-restart), restarting
Jun 25 04:06:44 nyi openvpn[30456]: SIGUSR1[soft,ping-restart] received, process restarting
Jun 25 04:06:46 nyi openvpn[30456]: UDPv4 link local: [undef]
Jun 25 04:06:46 nyi openvpn[30456]: UDPv4 link remote: [AF_INET]10.52.41.15:1194
Jun 25 04:06:47 nyi openvpn[30456]: [bast.example.org] Peer Connection Initiated with [AF_INET]10.52.41.15:1194
Jun 25 04:06:49 nyi openvpn[30456]: Preserving previous TUN/TAP instance: tun0
Jun 25 04:06:49 nyi openvpn[30456]: Initialization Sequence Completed
```


----------



## junovitch@ (Jun 26, 2014)

That is strange.  I agree with your initial skepticism as I would have expected the server side ccd directives to negate the need to have the ifconfig-pool-persist directives as well.  I usually have used both directives and haven't noticed this before though but I'm glad that everything worked out.


----------

