PfSense 2.2.1 + OpenVPN device busy | UPDATE 2.3

duren

I've been running pfSense 2.2 for a while and my OpenVPN connections have been rock solid. When upgrading to 2.2.1, I noticed that during a trigger such as ping-restart or service down, when the openvpn connection is restarting, it fails. I have three connections, two are failing with an error such as the one below, one is still up and working fine…

Mar 22 22:47:03 openvpn[60067]: Exiting due to fatal error
Mar 22 22:47:03 openvpn[60067]: Cannot open TUN/TAP dev /dev/tun2: Device busy (errno=16)
Mar 22 22:47:03 openvpn[60067]: TUN/TAP device ovpnc2 exists previously, keep at program end

The last of the three lines is normal

When I look at the sockets section, i see sockets open for openvpn pids 12505, 40062, 2460, but neither of those correspond to the pids in the openvpn log. In fact, every time the watchdog tries to restart the service, the error in the log shows a new PID.

It seems like those old instances were not shutdown correctly and thus new ones can't be created. I logged into the shell and killed those processes after which the watchdog successfully restarted and brought up connections.

I'll be monitoring the connections and follow up when I have more detail.

duren

I was going to post the following in another topic but just realized I think it's related…

My gateway monitors for those vpn connections were green / up even though the services showed down. This means that teardown of the old connections did not fully succeed for some reason, allowing the monitors to ping the alternatives IPs over the still functioning connections/gateways.

duren

I ran into this problem again when I upgraded to 2.3.

When the installation succeeded and pfSense rebooted, my OpenVPN clients were up (according to sockets and the fact that traffic was flowing) despite the dashboard showing "Can't connect, daemon running?" for each OpenVPN instance. Logs were also showing the tap/tun device busy errors.

I had to manually kill the OpenVPN processes shown in states and restart the clients. After that, everything appears to be working correctly.