Once a week OpenVPN tunnel drop in 2.2.[x]
-
Since updating from 2.1.5 to 2.2.1 at two different locations (one is now at 2.2.2), each respective OpenVPN tunnel to our HQ has stopped passing traffic almost like clockwork once a week on Sunday, although both sides still show the connection being up (by green arrow). The fix right now is to log into these two remote firewalls and restart the OpenVPN client service - this brings it back quickly. The HQ firewall (still at version 2.1.5) is set up as the OpenVPN server and the remote locations clients.
These are the client configs:
site 1 client
dev ovpnc3
dev-type tun
tun-ipv6
dev-node /dev/tun3
writepid /var/run/openvpn_client3.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local [public IP redacted]
lport 0
management /var/etc/openvpn/client3.sock unix
remote [route 192.168.1.0 255.255.255.0
secret /var/etc/openvpn/server8.secret
comp-lzo[b]site 2 client[/b]
dev ovpnc2
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local [public IP redacted]
lport 0
management /var/etc/openvpn/client2.sock unix
remote [url] 1190
ifconfig 172.22.1.30 172.22.1.29
route 192.168.0.0 255.255.255.0
secret /var/etc/openvpn/client2.secret
comp-lzo yes
resolv-retry infinite[b]site 2 server[/b]
dev ovpns10
dev-type tun
tun-ipv6
dev-node /dev/tun10
writepid /var/run/openvpn_server10.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 127.0.0.1
ifconfig 172.22.1.29 172.22.1.30
lport 1190
management /var/etc/openvpn/server10.sock unix
push "route 192.168.0.0 255.255.255.0"
route 192.168.9.0 255.255.255.0
secret /var/etc/openvpn/server10.secret
comp-lzoCould this have anything to do with the server still being at 2.1.5? Any help you could offer would be appreciated. :D
[/url]" target="_blank"> 1192
ifconfig 172.22.1.22 172.22.1.21
route 192.168.0.0 255.255.255.0
secret /var/etc/openvpn/client3.secret
comp-lzo adaptive
resolv-retry infinitesite 1 server
dev ovpns8
dev-type tun
tun-ipv6
dev-node /dev/tun8
writepid /var/run/openvpn_server8.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 127.0.0.1
ifconfig 172.22.1.21 172.22.1.22
lport 1192
management /var/etc/openvpn/server8.sock unix
push "route 192.168.0.0 255.255.255.0"
route 192.168.1.0 255.255.255.0
secret /var/etc/openvpn/server8.secret
comp-lzosite 2 client
dev ovpnc2
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local [public IP redacted]
lport 0
management /var/etc/openvpn/client2.sock unix
remote](1192<br />ifconfig 172.22.1.22 172.22.1.21<br />route 192.168.0.0 255.255.255.0<br />secret /var/etc/openvpn/client3.secret<br />comp-lzo adaptive<br />resolv-retry infinite<br /><br />[b]site 1 server[/b]<br /><br />dev ovpns8<br />dev-type tun<br />tun-ipv6<br />dev-node /dev/tun8<br />writepid /var/run/openvpn_server8.pid<br />#user nobody<br />#group nobody<br />script-security 3<br />daemon<br />keepalive 10 60<br />ping-timer-rem<br />persist-tun<br />persist-key<br />proto udp<br />cipher AES-128-CBC<br />up /usr/local/sbin/ovpn-linkup<br />down /usr/local/sbin/ovpn-linkdown<br />local 127.0.0.1<br />ifconfig 172.22.1.21 172.22.1.22<br />lport 1192<br />management /var/etc/openvpn/server8.sock unix<br />push ) [route 192.168.9.0 255.255.255.0
secret /var/etc/openvpn/server10.secret
comp-lzoCould this have anything to do with the server still being at 2.1.5? Any help you could offer would be appreciated. :D
" target="_blank"> 1190
ifconfig 172.22.1.30 172.22.1.29
route 192.168.0.0 255.255.255.0
secret /var/etc/openvpn/client2.secret
comp-lzo yes
resolv-retry infinitesite 2 server
dev ovpns10
dev-type tun
tun-ipv6
dev-node /dev/tun10
writepid /var/run/openvpn_server10.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 127.0.0.1
ifconfig 172.22.1.29 172.22.1.30
lport 1190
management /var/etc/openvpn/server10.sock unix
push "route 192.168.0.0 255.255.255.0"
route 192.168.9.0 255.255.255.0
secret /var/etc/openvpn/server10.secret
comp-lzoCould this have anything to do with the server still being at 2.1.5? Any help you could offer would be appreciated. :D](1190<br />ifconfig 172.22.1.30 172.22.1.29<br />route 192.168.0.0 255.255.255.0<br />secret /var/etc/openvpn/client2.secret<br />comp-lzo yes<br />resolv-retry infinite<br /><br />[b]site 2 server[/b] <br /><br />dev ovpns10<br />dev-type tun<br />tun-ipv6<br />dev-node /dev/tun10<br />writepid /var/run/openvpn_server10.pid<br />#user nobody<br />#group nobody<br />script-security 3<br />daemon<br />keepalive 10 60<br />ping-timer-rem<br />persist-tun<br />persist-key<br />proto udp<br />cipher AES-128-CBC<br />up /usr/local/sbin/ovpn-linkup<br />down /usr/local/sbin/ovpn-linkdown<br />local 127.0.0.1<br />ifconfig 172.22.1.29 172.22.1.30<br />lport 1190<br />management /var/etc/openvpn/server10.sock unix<br />push )
-
Fixed.
It appears I've figured out what was causing this, but not exactly why it was causing it.
The two locations having this problem each use their own 4G router as a backup WAN (set as tier 2 in a failover group that the LAN points to), and the router is set to automatically reboot every Sunday morning. When I tested by initiating a reboot of the 4G router with a running ping to the remote LAN network, sure enough the tunnel stopped passing traffic about 30 seconds after beginning the reboot. This happened reliably when trying it for both locations. Once again, going into the remote firewall and restarting the OpenVPN client connection brought it back.
So now it's a curiousity why bouncing a tier 2 and not-currently-active WAN connection would break an OpenVPN tunnel.