Service Stopped - Exiting due to fatal error

[Bambos]

Hello everyone, i'm facing strange error with pfsense 2.5.

Site to Site VPN was working fine, and suddenly i lost the tunnel with the server VPN. I had to travel on-site to see that openVPN service was stopped, and i just had to click start service. everything is ok now, reboot, again all ok.

any comments will be appreciated.
in logs i have found the following:

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
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)
Mar 29 19:42:13 openvpn 19774 write UDPv4: No route to host (code=65)
Mar 29 19:42:13 openvpn 19774 write UDPv4: No route to host (code=65)

[Gertjan]

Hi,

It's the log of an OpenVPN client, right ?

It started, using a remote [publicIP+port] and a local "192.168.10.242:0".
Then that local interface went down, and the OpenVPN client could use it any more :

TCP/UDP: Socket bind failed on local address [AF_INET]192.168.10.242:0: Can't assign requested address (errno=49)

[Bambos]

@gertjan Thank you,

is this a reason not to re-establish the tunnel ?
Is this a reason for the service to stop ?

[Gertjan]

You tell me.
I can't tell you what "]192.168.10.242" is, neither why disappeared.
But your OpenVPN clients needs it, as it wants to bind to it, as per your instructions.

For a connection to work, their needs to be a path.
Networks that go down tend to break paths.

[Bambos]

@gertjan Thanks for your comment.
192.168.10.242 was dhcp WAN from the internet provider. This changed and renewed.
This device was OpenVPN Client, and Server has static public IP.
I can understand the interruption caused from maybe an unreliable internet provider, but the question is why tunnel didn't re-established, and why the service was stopped and stay stopped.
Is there any settings i can tune ?

[Gertjan]

I'm using myself an upstream ISP router, and a RFC 1918 WAN IP.
This means the DHCP IP is renewed every week. The process takes a couple of milli seconds I guess. And as far as I know, the interface isn't taken down when the IP is renewed.

I just activated my OpenVPN client :
It connected.

The OpenVPN client log informs me all is well.

I went here :

and disconnected the WAN manually, waited a minute and connected again.

I just saw these lines in the OpenVPN client log :

which makes me think : your WAN interface went actually "down", down like : connector removed or powered down electrically (by the upstream router ?).
Not a normal condition - IMHO.

edit : re read your logs.

Your interface WAN goes down.
After many - how many ? - "write UDPv4: No route to host (code=65)" a time out arrives : a restart is executed.
Still, the WAN IP still isn't there .....
OpenVPN client says : "I quit".

Btw : check the OpenVPN doc/ manual : the "ping-restart" option : override its default setting by adding a bigger delay. So, when the network goes down, it has some tome to re establish a connection before the OpenVPN client tries to rebuild the connection.
You restart the connect at "30 08:20:57", right ?

[Bambos]

@gertjan yes right, i went physicly on site and press the start button on gui. I wait 12 hours before i go, so if something was about to restart or retry, let it happent. Please note that everything is working from that time up to now. What do you suggest ? Is there any package to restart the service ?

I saw in the past wireguard logs retrying every 5 seconds and then retrying every 5 minutes, expected something similar for OpenVPN.

[Gertjan]

Have a look at the main log page.
Figure out what happened at "Mar 29 19:42:21".
Why the WAN went down.

[Bambos]

@gertjan hello Sir,
I did some investigation and didn't find yet why the wan go down, though it never happent again. i'm thinking to implement a cron restart or watchdog for the services.
Thanks for your comments, i really appreciate your help.