Project

General

Profile

Bug #3243

OpenVPN does not rebind when gateway fails over

Added by Shahid Sheikh about 6 years ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
-
Start date:
09/29/2013
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.1
Affected Architecture:

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

  1. $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 != .
  2. $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

Associated revisions

Revision 78b2a705 (diff)
Added by Phillip Davis about 6 years ago

Fix logic inn detecting if OpenVPN resync needed

Commit https://github.com/pfsense/pfsense/commit/f33dcc5c79c54af7daf91a81cfdd7f489e8cb67c reversed the logic sequence when testing if $resync_needed - the individual tests were changed from "==" to "!=" and so on, but the conjunction also need to be changed - "or" needs to be "and". I had noticed that VPNs on some gateway groups of mine didn't failover recently, but hadn't gone looking for the problem until now.
This might help bug #3243 - it will probably now make the OpenVPN resync on every interface/gateway change for the cases of CARP VIPs and VLANs mentioned in that bug report. At least that will be better than not resyncing at all.

Revision 4bf23d32 (diff)
Added by Phillip Davis almost 6 years ago

Fix logic inn detecting if OpenVPN resync needed

Commit https://github.com/pfsense/pfsense/commit/f33dcc5c79c54af7daf91a81cfdd7f489e8cb67c reversed the logic sequence when testing if $resync_needed - the individual tests were changed from "==" to "!=" and so on, but the conjunction also need to be changed - "or" needs to be "and". I had noticed that VPNs on some gateway groups of mine didn't failover recently, but hadn't gone looking for the problem until now.
This might help bug #3243 - it will probably now make the OpenVPN resync on every interface/gateway change for the cases of CARP VIPs and VLANs mentioned in that bug report. At least that will be better than not resyncing at all.

History

#1 Updated by Phillip Davis about 6 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...

#2 Updated by Jim Pingle 2 months ago

  • Status changed from New to Resolved

PR was merged long ago

Also available in: Atom PDF