https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162013-03-28T23:53:50ZpfSense bugtrackerpfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=112002013-03-28T23:53:50ZChris Buechlercbuechler@gmail.com
<ul></ul><p>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).</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=112012013-03-29T01:17:54ZPhillip Davisphil@jankaritech.com
<ul></ul><p>/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.<br />/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.<br />Is that a reasonable way to go?</p>
<p>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?</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=112932013-04-12T15:06:07ZErmal Luçieri@pfsense.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>Several fixes committed related to this.</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=112982013-04-14T00:53:55ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>New</i></li></ul><p>Still not started on hot plug whether using a gateway group or not.</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=113132013-04-16T06:30:07ZRenato Botelhorenato@netgate.com
<ul></ul><p>Chris Buechler wrote:</p>
<blockquote>
<p>Still not started on hot plug whether using a gateway group or not.</p>
</blockquote>
<p>Could you try it with a more recent snapshot (>= April 15)? A binary upgrade is necessary because check_reload_status was updated</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=113422013-04-19T13:44:02ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=113822013-04-26T07:46:10ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>New</i></li></ul><p>Seems to still be a problem on a snap from the 24th, especially with VPN instances bound to Gateway Groups.</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=114332013-05-07T02:52:14ZPhillip Davisphil@jankaritech.com
<ul></ul><p>This pull request makes it all work as far as I can see: <a class="external" href="https://github.com/pfsense/pfsense/pull/625">https://github.com/pfsense/pfsense/pull/625</a><br />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.</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=114352013-05-07T10:26:27ZPhillip Davisphil@jankaritech.com
<ul></ul><p>The optimized version is pull request <a class="external" href="https://github.com/pfsense/pfsense/pull/627">https://github.com/pfsense/pfsense/pull/627</a><br />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.</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=114382013-05-07T11:38:32ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>Should be fixed after pull request was merged</p> pfSense - Bug #2915: OpenVPN server/client not started after WAN physical hotplug eventhttps://redmine.pfsense.org/issues/2915?journal_id=114682013-05-09T07:30:16ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>confirmed working</p>