Project

General

Profile

Actions

Bug #12075

closed
JP VG

Changes to an existing IPsec configuration are not applied on HA secondary after XMLRPC sync

Bug #12075: Changes to an existing IPsec configuration are not applied on HA secondary after XMLRPC sync

Added by Jim Pingle about 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Viktor Gurov
Category:
XMLRPC
Target version:
Start date:
06/23/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

When synchronizing settings over XMLRPC, the secondary only reconfigures the IPsec daemon if IPsec is enabled or disabled as a whole and not for other changes.

If a setting is changed on an existing setup, such as altering a PSK or adding a new tunnel, the secondary gets the settings in config.xml but they are not activated in strongswan. For example, new settings are not reflected in /var/etc/swanctl.conf until something else comes along and reloads them (e.g. manually, reboot, etc).

Normally the settings should be applied on sync, but in some cases that could lead to the secondary interfering in active tunnels, so testing and care is needed to ensure it is not disruptive. Settings could also be applied during transition to CARP master but that could be prone to timing issues.


Related issues 1 (0 open1 closed)

Related to Bug #12566: IPsec initiates on HA backup node when a tunnel interface is set to a gateway groupClosedViktor Gurov

Actions

MM Updated by Marcos M about 5 years ago Actions #1

Perhaps it could be treated similarly to FRR and OpenVPN where the secondary checks whether its interface is CARP, and if so, it only starts the service if it's interface is in master.

VG Updated by Viktor Gurov about 5 years ago Actions #3

PH1 entries with BACKUP VIP or VIPs aliased to BACKUP CARP must be skipped in `ipsec_get_phase1_src()` (see also https://redmine.pfsense.org/issues/11793) - otherwise secondary node tries to start CARP-binded PH1 entries after reboot

JP Updated by Jim Pingle about 5 years ago Actions #4

  • Status changed from New to Pull Request Review

JP Updated by Jim Pingle about 5 years ago Actions #5

Copied from my comments on the PR:

Skipping entries negates the entire point of doing the configure during XMLRPC sync. You may as well just reconfigure during the CARP transition if you're going to do that.

Rather than skipping entries, set the child SA start action to 'none' on sync when using a CARP VIP in backup status, and then when it changes to master, resync and let it be whatever the user set (or default if unset). When child SA start action is 'none' it won't attempt to automatically initiate.

RB Updated by Renato Botelho about 5 years ago Actions #6

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Viktor Gurov

PR has been merged. Thanks!

VG Updated by Viktor Gurov about 5 years ago Actions #7

  • % Done changed from 0 to 100

Applied in changeset commit:6ae26227e1ce622ff9bec0999bb829cec92373e8.

ML Updated by Max Leighton almost 5 years ago Actions #8

This seems to work for me. When I make changes to an existing tunnel's encryption settings, interface, local ID, etc, /var/etc/ipsec/swanctl.conf on the secondary immediately reflects the changes without any manual intervention. However, I am not able to replicate the initial problem in 2.5.2 so it's not clear if this only affected earlier builds 2.6?

Tested in

2.6.0-DEVELOPMENT (amd64)
built on Sat Oct 09 05:20:31 UTC 2021
FreeBSD 12.2-STABLE

MM Updated by Marcos M almost 5 years ago Actions #9

  • Status changed from Feedback to Resolved

Tested on 22.01.a.20211010.0500 with configuration that I originally experienced the issue in. It works correctly now.

JP Updated by Jim Pingle almost 5 years ago Actions #10

  • Plus Target Version changed from 21.09 to 22.01

VG Updated by Viktor Gurov almost 5 years ago Actions #11

  • Related to Bug #12566: IPsec initiates on HA backup node when a tunnel interface is set to a gateway group added
Actions

Also available in: Atom