Bug #3243
closedOpenVPN does not rebind when gateway fails over
0%
Description
function openvpn_resync_if_needed ($mode, $ovpn_settings, $interface) { global $g, $config; $resync_needed = true; if (!empty($interface)) { $mode_id = $mode . $ovpn_settings['vpnid']; $fpath = "{$g['varetc_path']}/openvpn/{$mode_id}.interface"; if (file_exists($fpath)) { $current_device = file_get_contents($fpath); $current_device = trim($current_device, " \t\n"); $new_device = get_failover_interface($ovpn_settings['interface']); if (isset($config['interfaces'][$interface])) { $this_device = $config['interfaces'][$interface]['if']; if (($current_device == $new_device) || ($current_device != $this_device) || ($new_device != $this_device)) $resync_needed = false; } } } if ($resync_needed == true) { log_error("OpenVPN: Resync " . $mode_id . " " . $ovpn_settings['description']); openvpn_resync($mode, $ovpn_settings); } }
When a gateway group is tied to CARP VIPs and OpenVPN client or server is bound to a gateway group, $resync_needed always gets set to false and OpenVPN never reloads on gateway failover.
That is because
$current_device
is the name of the VIP (e.g. wan_vip1) and$this_device
is the interface (e.g. em1) so they are always != .$new_device
is, again, the name of the VIP GWGroup failed over to (e.g. opt2_vip2) and$this_device
is the interface (e.g. em1) so they are always != .
This also fails when VLANs are in use and GWGroup is bound to the interface address of a VLAN. Again because $this_device
is the interface (e.g. em1) and it will never be equal to $current_device
or $new_device
, both of which will have "vlan" in the name (e.g. em2_vlan51).
Why do these two comparisons need to be in there to begin with:
($current_device != $this_device)
and($new_device != $this_device)
Isn't this comparison ($current_device == $new_device)
enough to determine if the OpenVPN should reload or not?
Thanks,
Shahid
Updated by Phillip Davis about 11 years ago
Pull request: https://github.com/pfsense/pfsense/pull/813
I think the logic got messed up with a recent change. Look at the pull request and my comments on it. I think that should put the behaviour back the way it was, so OpenVPN instances will resync.
For the CARP VIP and VLAN cases that you mention, I think it will now always resync when a gateway goes down or up. That would have been the behaviour in the past, so at least the system will work. But that could be made more optimal for CARP VIP and VLAN when a low-tier gateway goes down/up and actually the OpenVPN instance is already in the rigght place and running happily - they were the cases I was trying to cover, and avoid unnecessary OpenVPN restarts.
I have a system at work with 2 WANs on VLANs, so I will test that tomorrow morning...