Bug #12472
closed
IPsec Keep Alive does not work correctly with gateway groups in HA
Added by Marcos M about 3 years ago.
Updated about 3 years ago.
Plus Target Version:
22.01
Release Notes:
Force Exclusion
Description
In ipsec_keepalive.php
: (substr($status[$ikeid]['p1']['interface'], 0, 4) == "_vip")
returns a false negative when the interface is a gateway group due to ['interface'] at this point being defined as the gateway group name. This leads to the secondary incorrectly initiating a connection.
It's difficult to determine if specific interfaces of a gateway group are being used for CARP VIP too, since the configuration of the gateway group uses gateways (which use interfaces) but not VIP
Viktor Gurov wrote in #note-1:
It's difficult to determine if specific interfaces of a gateway group are being used for CARP VIP too, since the configuration of the gateway group uses gateways (which use interfaces) but not VIP
Presumably in this case the user should have selected a CARP VIP when creating or editing a gateway group using the Virtual IP field there. In other areas that is used to influence which VIP is associated with an interface in a gateway group.
So perhaps it could have another check that compares against that value, though it does add a bit more complexity.
There exists checks in other areas that could be adapted for this:
https://gitlab.netgate.com/pfSense/pfSense/blob/master/src/etc/inc/openvpn.inc#L1580
/* Check if client is bound to a gateway group */
$a_groups = return_gateway_groups_array(true);
if (is_array($a_groups[$settings['interface']])) {
/* the interface is a gateway group. If a vip is defined and its a CARP backup then do not start */
if (($a_groups[$settings['interface']][0]['vip'] <> "") && (!in_array(get_carp_interface_status($a_groups[$settings['interface']][0]['vip']), array("MASTER", "")))) {
unlock($lockhandle);
return;
}
}
- Status changed from New to Pull Request Review
- Assignee set to Viktor Gurov
- Target version set to 2.6.0
- Plus Target Version set to 22.01
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
- Release Notes changed from Default to Force Exclusion
This was an issue with a newly added feature, so it does not need to be in the release notes.
FWIW this works correctly now - tested on 22.01.a.20211204.0600
.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF