Bug #2915
closed
OpenVPN server/client not started after WAN physical hotplug event
0%
Description
Easy to reproduce - setup OpenVPN client on interface WAN. Have it running connected to a server somewhere. Physically unplug the WAN. The client dies (this is OK - OpenVPN does not like to remain bound to an IP of a physical interface that has gone away). Plug the WAN cable again, the WAN interface comes up, internet is available again. But the OpenVPN client is never started. The same problem is expected to happen with a server.
If the client/s or server/s use a gateway group as an interface, then they are started.
Problem is in /etc/rc.openvpn - it only tries to start OpenVPN servers and clients that use a gateway group.
The easy fix is to make rc.openvpn restart all OpenVPN (like it used to about 9 months ago). However, in complex configs it would be nice NOT to restart every OpenVPN when some crappy little interface goes down and up. If rc.openvpn had some knowledge of which interface had come up, then it could be smart and restart just:
- OpenVPN that use that interface
- OpenVPN of any gateway group that now has that interface as the highest tier
Updated by Chris Buechler about 11 years ago
as long as it only impacts OpenVPN instances on the interface where the event occurred, it should be fine to call resync on all instances on that interface (or on a gateway group where that interface is involved).
Updated by Phillip Davis about 11 years ago
/etc/rc.openvpn does not get passed the interface, so it has no idea what is going on. I can't see an easy way to get all that check_reload_status/send_event stuff to pass the interface name all the way through.
/etc/inc/interfaces.inc interface_configure() gets called by rc.linkup and other good things - it looks like there could be a routine added to openvpn.inc openvpn_resync_interface($interface) that has all the smarts to resync all OpenVPNs related to the interface given. Then interface_configure() can call it. rc.newwanip could also call openvpn_resync_interface() instead of openvpn_resync_all(), as it also does not need to reset the whole universe of OpenVPN. And anywhere else that handles interface changes that effect OpenVPN.
Is that a reasonable way to go?
Note: gwlb.inc setup_gateways_monitor() also allows apinger to send "service reload openvpn", which will cause check_reload_status to run /etc/rc.openvpn, which reloads the OpenVPN universe - that seems to happen every time some dodgy gateway gets some packet loss, latency... - should that be the thing that is improved to somehow pass the interface through from apinger?
Updated by Ermal Luçi about 11 years ago
- Status changed from New to Feedback
Several fixes committed related to this.
Updated by Chris Buechler about 11 years ago
- Status changed from Feedback to New
Still not started on hot plug whether using a gateway group or not.
Updated by Renato Botelho about 11 years ago
Chris Buechler wrote:
Still not started on hot plug whether using a gateway group or not.
Could you try it with a more recent snapshot (>= April 15)? A binary upgrade is necessary because check_reload_status was updated
Updated by Renato Botelho about 11 years ago
- Status changed from New to Feedback
Updated by Jim Pingle almost 11 years ago
- Status changed from Feedback to New
Seems to still be a problem on a snap from the 24th, especially with VPN instances bound to Gateway Groups.
Updated by Phillip Davis almost 11 years ago
This pull request makes it all work as far as I can see: https://github.com/pfsense/pfsense/pull/625
There is some more optimization that can be done. For a gateway group using multiple tiers, if one of the lower-priority gateway/interfaces goes down or up, then there is no need to restart OpenVPN instances that are happily running on the working higher-priority (e.g. Tier 1) interface/s. I will have a look at that, since I think it is worth doing. People tend to "play" with the backup links, thinking that they can plug/unplug them with no consequences as long as the primary WAN is not touched - it would be nice if this were true.
Updated by Phillip Davis almost 11 years ago
The optimized version is pull request https://github.com/pfsense/pfsense/pull/627
I believe this is all working nicely now. Once people have had a chance to try/test it for real in upcoming snapshots, this bug report can be closed.
Updated by Renato Botelho almost 11 years ago
- Status changed from New to Feedback
Should be fixed after pull request was merged
Updated by Chris Buechler almost 11 years ago
- Status changed from Feedback to Resolved
confirmed working