Bug 12740 - Core Update 162 (testing): IPsec N2N connections do not get reestablished afterwards
Summary: Core Update 162 (testing): IPsec N2N connections do not get reestablished aft...
Status: CLOSED WORKSFORME
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect most users Balancing
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact: Peter Müller
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-05 14:11 UTC by Peter Müller
Modified: 2022-06-28 14:22 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2021-12-05 14:11:19 UTC 
While upgrading to Core Update 162 (testing), I noticed IPFire won't reestablish IPsec N2N connections being in "active" mode by itself. Instead, manually starting them via the WUI or "ipsec up [connection]" was necessary.

This is a bit of a nuisance, especially if an IPFire machine is upgraded remotely over an IPsec connection, where the administrator does not have access to the IPsec gateway he/she is located behind.

This problem already appeared in Core Update 161, and seems to be related to a strongSwan update. It is not to be confused with #12725, as established N2N connections where the local IPFire machine is not set into "on demand" mode run stable.

See also:
- https://lists.ipfire.org/pipermail/development/2021-November/011539.html
- https://community.ipfire.org/t/update-to-161-ipsec-wont-connect-anywhere-afterwards/6707/3
Comment 1 Peter Müller 2022-06-28 14:22:28 UTC 
Investigating this closer during the recent Core Updates, I am unable to reproduce the behaviour. Therefore, closing this.