OpenVPN Site to Site Service stopped - fatal error

Networking & Firewalls
1

I have a strange issue using pfsense2.5 and protectli appliance. This firewall is client on a site to site configuration, ISP is WAN DHCP. Server firewall has static public IP.
The tunnel was up and fine, until an incident.
I had to physicly go on-site to start the open VPN Service again. Please note from the moment i manually press start service, is working properly.
I don’t know why didn’t retry to re-establish the tunnel, and i don’t know why the service stopped.
Is there any settings for that , retry, re-establish etc ?

after checking the logs i found the following:

fault here

Mar 29 19:42:21 openvpn 19774 /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1560 172.17.27.2 172.17.27.1 init
Mar 29 19:42:21 openvpn 19774 Exiting due to fatal error
Mar 29 19:42:21 openvpn 19774 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.10.242:0: Can’t assign requested address (errno=49)
Mar 29 19:42:21 openvpn 19774 TCP/UDP: Preserving recently used remote address: [AF_INET][publicIP+port]
Mar 29 19:42:21 openvpn 19774 Preserving previous TUN/TAP instance: ovpnc1
Mar 29 19:42:21 openvpn 19774 Re-using pre-shared static key
Mar 29 19:42:21 openvpn 19774 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 29 19:42:16 openvpn 19774 SIGUSR1[soft,ping-restart] received, process restarting
Mar 29 19:42:16 openvpn 19774 Inactivity timeout (–ping-restart), restarting
Mar 29 19:42:15 openvpn 19774 write UDPv4: No route to host (code=65)
Mar 29 19:42:15 openvpn 19774 write UDPv4: No route to host (code=65)
Mar 29 19:42:14 openvpn 19774 write UDPv4: No route to host (code=65)
Mar 29 19:42:14 openvpn 19774 write UDPv4: No route to host (code=65)

After i press start service

Mar 30 08:20:57 openvpn 63636 Peer Connection Initiated with [AF_INET][publicIP+port]
Mar 30 08:20:57 openvpn 63636 UDPv4 link remote: [AF_INET][publicIP+port]
Mar 30 08:20:57 openvpn 63636 UDPv4 link local (bound): [AF_INET]192.168.10.242:0
Mar 30 08:20:57 openvpn 63636 TCP/UDP: Preserving recently used remote address: [AF_INET][publicIP+port]
Mar 30 08:20:57 openvpn 63636 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1560 172.17.27.2 172.17.27.1 init
Mar 30 08:20:57 openvpn 63636 /sbin/ifconfig ovpnc1 172.17.27.2 172.17.27.1 mtu 1500 netmask 255.255.255.255 up
Mar 30 08:20:57 openvpn 63636 TUN/TAP device /dev/tun1 opened
Mar 30 08:20:57 openvpn 63636 TUN/TAP device ovpnc1 exists previously, keep at program end
Mar 30 08:20:57 openvpn 63636 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 30 08:20:57 openvpn 63567 library versions: OpenSSL 1.1.1i-freebsd 8 Dec 2020, LZO 2.10
Mar 30 08:20:57 openvpn 63567 OpenVPN 2.5.0 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Feb 5 2021
Mar 30 08:20:57 openvpn 63567 Cipher negotiation is disabled since neither P2MP client nor server mode is enabled

2

Can’t say why your connection failed but having a remote connection I need to keep up I have installed three openvpn servers and included them in the service watchdog so if they do fail they ought to be restarted. Belts and braces approach.

With 2.5 there were many changes with openVPN so you need to read through them to see if you are affected by anything. I’m on 2.4.5 FYI.

3

@neogrid Thank you for comments. Both firewalls are installed fresh 2.5. What do you suggest for restarting the service in case of failure (or even hourly) ? is this watchdog a package ?

4

Yes you can install the watchdog package, then open it up and you will be able to select your openVPN servers.

Though if there is fundamental problem in your config, then that will need to be resolved.

Initially I too set up site to site however, you now see the downside, instead I’ve setup the servers and clients on both ends with static routes, so if one connection goes down the other is still up.

I must admit, after putting in place these measures they haven’t failed hence I also can’t confirm they will work either but the effort isn’t high.