Bug #4341
closed
strongSwan fails to re-attach dynamic IPs where interfaces_use specified
Added by Sebastian Chrostek almost 10 years ago. Updated over 9 years ago.
0%
Description
I have a single WAN setup with PPPOE
IPsec (problem applies to both: IKE1 and IKE2)
Every 24 hours the WAN gets reconnected (German Telekom)
After this the IPsec does not reconnect:
charon: 14[IKE] peer not responding, trying again (3/3)
This happens on multiple systems (i386 and amd64). Even on systems with a fixed IP address.
Restarting the ipsec service does not solve the problem. I need to stop and start the service to get a connection again.
Updated by Bob Gray almost 10 years ago
Same issue using a PPP wan with Orange France ISP using a dynamic IP. Everything was working fine before pfsense 2.2/strongSwan migration.
Both node are using pfsense 2.2, and the only way to fix this is to stop/start (restart does not work) ipsec on the node using PPP.
Updated by Jan-Hendrik Wittke almost 10 years ago
Same issue one Box using a PPP wan with O2/Alice ISP using a dynamic IP and other Box using DHCP with Kabeldeutschland ISP.
Everything was working fine before pfsense 2.2/strongSwan migration.
Both node are using pfsense 2.2, and the only way to fix this is to stop/start (restart does not work) ipsec on both nodes!
Updated by Jan-Hendrik Wittke almost 10 years ago
Same issue using a DHCP wan with Kabeldeutschland Cable ISP using a dynamic IP and the other node using a PPP wan with O2/Alice ISP using a fixed IP. Everything was working fine before pfsense 2.2/strongSwan migration.
One node is using pfsense 2.2, and the other is 2.1.5 the only way to fix this is to stop/start (restart does not work) ipsec on the pfsense 2.2 node. Nothing todo on the 2.1.5 node!!!
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Confirmed
- Assignee set to Ermal Luçi
- Priority changed from High to Very High
- Target version set to 2.2.1
Found a scenario where this is replicable with PPPoE.
1) setup IPsec bound to a PPPoE WAN, with no keepalive defined and nothing running in the background that will trigger the connection
2) bring the system up on a clean boot, go to Status>Interfaces and disconnect the PPPoE. Then reconnect it.
3) initiate some traffic that triggers the IPsec connection to come up.
It'll end up with logs along the lines of the following:
Feb 16 20:43:23 charon: 11[IKE] giving up after 5 retransmits
Feb 16 20:43:23 charon: 11[IKE] <con3000|2> giving up after 5 retransmits
Feb 16 20:43:23 charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:43:23 charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:43:10 charon: 09[CFG] ignoring acquire, connection attempt pending
Feb 16 20:43:10 charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:43:01 charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:43:01 charon: 09[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:48 charon: 09[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:48 charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:38 charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:38 charon: 09[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:26 charon: 09[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:26 charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:16 charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:16 charon: 09[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:07 charon: 09[NET] sending packet: from 203.0.113.77[500] to 100.64.25.22[500] (200 bytes)
and fail to come up. Stop and start strongswan and it comes up right away. If the connection is up before you disconnect PPPoE, whether via Status>Interfaces or by forcing a reconnect at the PPPoE server side, it picks up immediately as soon as the connection is back up.
In this specific circumstance, strongswan shows it's seeing the interface events.
Feb 16 20:34:25 pfs22-ipsectest4 charon: 11[KNL] 203.0.113.77 disappeared from pppoe1 Feb 16 20:34:27 pfs22-ipsectest4 charon: 11[KNL] interface pppoe1 disappeared Feb 16 20:34:33 pfs22-ipsectest4 charon: 10[KNL] interface pppoe1 appeared Feb 16 20:34:33 pfs22-ipsectest4 charon: 10[KNL] 203.0.113.77 appeared on pppoe1 Feb 16 20:34:33 pfs22-ipsectest4 charon: 10[KNL] fe80::250:56ff:fea7:7031 appeared on pppoe1
and 'ipsec statusall' shows the pppoe1 IP missing from "Listening IP addresses".
Listening IP addresses: 198.51.100.77
only the other WAN where this system has an IPsec connection bound. A reload doesn't make the IP come back. A full restart brings it back to normal.
Listening IP addresses: 198.51.100.77 203.0.113.77
Updated by Chris Buechler almost 10 years ago
- Subject changed from IPsec does not reconnect after WAN reconnect to strongSwan fails to re-attach dynamic IPs where interfaces_use specified
Updated subject should be accurate of specific issue. Removing interfaces_use from strongswan.conf makes the problem go away. Though 'ipsec statusall' still shows the IP missing under "Listening IP addresses", it works fine.
Updated by Sam Bernard almost 10 years ago
Chris, will you merge BUG #4425 with this one. I had filed that bug report to outline the same problem that you have been able to confirm here. It was first outlined in my forum post https://forum.pfsense.org/index.php?topic=87636.msg482884#msg482884. I have provided logs on there too if you guys need for testing.
Updated by Chris Buechler over 9 years ago
- Assignee changed from Ermal Luçi to Chris Buechler
there are issues in strongswan with the interfaces_use option. For now, we'll disable it by default, and add a checkbox to Advanced to enable it should there be scenarios we're unaware of where this is desirable.
Updated by Chris Buechler over 9 years ago
- Status changed from Confirmed to Feedback
Updated by Sam Bernard over 9 years ago
Chris I see you marked this issue as Resolved. Is there a PATCH for the 2.2 version that we can apply until we await 2.2.1.
SAM
Updated by Renato Botelho over 9 years ago
Sam Bernard wrote:
Chris I see you marked this issue as Resolved. Is there a PATCH for the 2.2 version that we can apply until we await 2.2.1.
SAM
You can get 2.2.1 snapshots or apply the patch from https://github.com/pfsense/pfsense/commit/eb6495c3b1dfdd3639a01bb27e7bf2285f9ae2ce on 2.2
Updated by Sam Bernard over 9 years ago
Tried with the patch.. still does NOT work. Charon still does not re-establish the IPsec connections on PPPoE