Service not running? Unable to contact daemon error

Styg

Configuration.

2 PFsenses on each site, 2 ISPs on each site. CARP is configured for both LAN and WAN interfaces, one pfsense is master, second is backup. Two tunnels are up simultaneously using different ISPs, quagga/ospf handles routing.

One site works as server and the other site connects as client. Sometimes on client site OpenVPN status page shows link down, service not running, Unable to contact daemon. And unlike other cases I found here with the same mistake in my case tunnel is really down. ps -auxww|grep openvpn shows only one openvpn process running. Manual start fails as well, reading in system log

Sep 30 12:05:54	kernel: ovpnc2: link state changed to DOWN
Sep 30 12:05:54	kernel: ifa_add_loopback_route: insertion failed
Sep 30 12:05:54	kernel: ovpnc2: link state changed to UP

OpenVPN log

Last 2000 OpenVPN log entries
Sep 30 12:05:54	openvpn[57046]: Exiting due to fatal error
Sep 30 12:05:54	openvpn[57046]: FreeBSD ifconfig failed: external program exited with error status: 1
Sep 30 12:05:54	openvpn[57046]: /sbin/ifconfig ovpnc2 10.0.1.6 10.0.1.5 mtu 1500 netmask 255.255.255.255 up
Sep 30 12:05:54	openvpn[57046]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Sep 30 12:05:54	openvpn[57046]: TUN/TAP device /dev/tun2 opened
Sep 30 12:05:54	openvpn[57046]: TUN/TAP device ovpnc2 exists previously, keep at program end
Sep 30 12:05:52	openvpn[57046]: [tlngw srv] Peer Connection Initiated with [AF_INET]REMOTE_WAN_VIP1:port
Sep 30 12:05:52	openvpn[57046]: WARNING: 'ifconfig' is present in remote config but missing in local config, remote='ifconfig 10.0.1.6 10.0.1.5'
Sep 30 12:05:52	openvpn[57046]: WARNING: 'tun-ipv6' is present in remote config but missing in local config, remote='tun-ipv6'
Sep 30 12:05:51	openvpn[57046]: UDPv4 link remote: [AF_INET]REMOTE_WAN_VIP1:port
Sep 30 12:05:51	openvpn[57046]: UDPv4 link local (bound): [AF_INET]WAN_VIP1
Sep 30 12:05:51	openvpn[56748]: Control Channel Authentication: using '/var/etc/openvpn/client2.tls-auth' as a OpenVPN static key file
Sep 30 12:05:51	openvpn[56748]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 30 12:05:51	openvpn[56748]: WARNING: using --pull/--client and --ifconfig together is probably not what you want
Sep 30 12:05:51	openvpn[56748]: OpenVPN 2.3.3 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014

The only way I have found to fix this is to start service manually and everything starts to work. But the idea was to create fail safe configuration with minimum required interaction. PFSense should switch the tunnels if one ISP goes offline and switch back when that ISP is back online. Now I have to check connection frequently and start the service if it stops. Any help would be appreciated.

Styg

Small update here. Nothing really changed, though. I keep getting this message from time to time and I can reproduce it merely restarting the ovpn service on server side. As long as I use UDP, client always gives the same error, client ovpn service stops and does not try to reconnect. It does not happen using TCP though, but TCP is much slower. Currently I use UDP, I increased the number of tunnels to 4 and I added Zabbix ping monitoring of tunnels and email notification on ping loss, so now I am reported when I have to log in and start ovpn services manually. And I still do not have a slightest idea why the service just stops.

cmb

You're advertising your OpenVPN tunnel networks in OSPF, which will break in the way you show as it's trying to route what should be the local tunnel network over the other VPN. Don't announce the tunnel networks in OSPF and you'll be set from the looks of it.

Styg

Thank you very much for pointing to OSPF direction. Quagga behaves wierd a bit, exactly as written in this thread. I had to add tunnel adresses manually, as advised here , and it worked for me. Everything runs fine for two weeks already, client reconnects properly. Restaring server side of OVPN tunnel does not crash client side anymore. The issue is solved.