Bug #6936
closed
OpenVPN client boot race causes intermittent dependent rule failure.
0%
Description
Summary:
A race condition starting OpenVPN client at boot (rc.bootup) is causing a firewall rule (that is dependent upon the OpenVPN gateway) to fail to initialise.
The failure is intermittent, but occurs around 50% of the time on my system.
Manually restarting the OpenVPN client service (after boot) clears the fault (properly initialises the rule) 100% of the time.
pfSense version 2.3.2 and 2.3.2-p1 running as Linux KVM guest on amd64.
Workaround:
Moving the call to openvpn_resync_all() in /etc/rc.bootup further down has resolved the boot-time failure completely.
(I have moved the call to below setup_gateways_monitor(), but I am not familiar enough with the code to know where the dependency actually is, it may just be that the added delay is sufficient in my case).
Details of failure state (immediately after boot sequence is complete):
- web interface shows OpenVPN client status as "up"
- OpenVPN log has the following entry:
/usr/local/sbin/ovpn-linkup ovpnc1 1500 1558 10.XX.XX.XX 255.255.0.0 init
- System log has the following entry:
/rc.newwanip:rc.newwanip:on (IP address:10.XX.XX.XX)(interface: VPN_WAN[opt2])(real interface:ovpnc1).
- verified at CLI with ifconfig and ping to vpn peer.
- pfctl does not show expected rule.
- /tmp/rules.debug contains the following line:
# rule LAN ALLOW OUTBOUND disabled because gateway VPN_GATEWAY is down label "USER_RULE: LAN ALLOW OUTBOUND"
Updated by Gavin Stewart about 9 years ago
Please note that Status -> Filter Reload also works to properly initialise the rule after boot (as an alternative to manually restarting the OpenVPN client service).
Updated by Jim Pingle about 9 years ago
Do you have System > Advanced, Misc, "Do not create rules when gateway is down" set?
Updated by Jim Pingle about 9 years ago
Moving the start of OpenVPN will undoubtedly have other unintended consequences. What is likely happening here is that the pileup of events when the system is booting is causing some, like the gateway coming up, to be ignored.
First, try to reproduce the problem on 2.4 if you can. If it's still a problem there, we can look deeper, maybe it will require one last filter reload to trigger at the very end of the boot sequence. I thought we had recently added something like that for a different ticket, though.
Updated by Gavin Stewart about 9 years ago
I have now verified that this is reproducible on 2.4 nightly 20161116-0701.
Updated by → luckman212 almost 9 years ago
Gavin
Have you retested on a recent 2.4 snap?
Updated by Jim Pingle almost 9 years ago
There is a good chance this has been fixed by #6132 so it's worth trying on a current 2.4 snapshot.
Updated by Jim Pingle over 6 years ago
- Status changed from New to Closed
No feedback, and likely fixed by other work (see previous comments)