# How to keep OpenVPN alive?



## aragats (Apr 7, 2020)

What's the best practice?
OpenVPN client dies when connectivity disrupts or OpenVPN server restarts.
Of course, I could use sysutils/monit, but I think there must be more "native" means.


----------



## SirDice (Apr 8, 2020)

aragats said:


> OpenVPN client dies when connectivity disrupts or OpenVPN server restarts.


Does OpenVPN itself stop working (crashing)? Because normally the connection is automatically restored. Nothing special has to be done for this.


----------



## msplsh (Apr 8, 2020)

I'll get this sort of error and `openvpn-client` will fail to maintain:


```
TUN/TAP device tap0 exists previously, keep at program end
Cannot open TUN/TAP dev /dev/tap0: Permission denied (errno=13)
Exiting due to fatal error
```


----------



## obsigna (Apr 8, 2020)

aragats said:


> ...
> Of course, I could use sysutils/monit, but I think there must be more "native" means.



In case „more native“ means some utility which is in FreeBSD base, you may want to look at daemon(8). In -r mode, it supervises and restarts the program after a one-second delay if it has been terminated. Now, supervising is not done by polling, because the respective programs are child processes and daemon knows immediately once a child dies.

OTH, if it is really a problem that /dev/tap0 was not correctly destroyed and cannot be reopened by a new OpenVPN process, like msplsh suggested, then daemon cannot do anything about it either.


----------



## aragats (Apr 8, 2020)

SirDice said:


> Because normally the connection is automatically restored. Nothing special has to be done for this.


That's what I thought. Actually it never brakes in a pfSense box, but brakes regularly in several FreeBSD and Linux boxes. The OpenVPN server is running in FreeBSD.


msplsh said:


> Cannot open TUN/TAP dev /dev/tap0: Permission denied


Isn't it tun0, not tap0?


obsigna said:


> if it is really a problem that /dev/tap0 was not correctly destroyed and cannot be reopened by a new OpenVPN process ..., then daemon cannot do anything about it either


I remember seeing something like that in the past, I cannot break the working network at the moment to check, and old logs are gone. The thing is that manually restarting the service with `service openvpn restart` always works.


----------



## msplsh (Apr 8, 2020)

The correct device depends on your configuration, so, no.


----------



## Lamia (Apr 9, 2020)

aragats said:


> That's what I thought. Actually it never brakes in a pfSense box, but brakes regularly in several FreeBSD and Linux boxes. The OpenVPN server is running in FreeBSD.
> 
> Isn't it tun0, not tap0?
> 
> I remember seeing something like that in the past, I cannot break the working network at the moment to check, and old logs are gone. The thing is that manually restarting the service with `service openvpn restart` always works.


Manually restarting it does not always work, particularly if it is in a jail. The jail may need to be restarted owing to the tun/tap interface.


----------

