https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-01-31T08:20:04ZpfSense bugtrackerpfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=171152015-01-31T08:20:04ZBob Graypfoo@csnu.org
<ul></ul><p>Same issue using a PPP wan with Orange France ISP using a dynamic IP. Everything was working fine before pfsense 2.2/strongSwan migration.<br />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.</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=171802015-02-05T13:09:32ZJan-Hendrik Wittkeinfo@j-hmw.de
<ul></ul><p>Same issue one Box using a PPP wan with O2/Alice ISP using a dynamic IP and other Box using DHCP with Kabeldeutschland ISP.<br />Everything was working fine before pfsense 2.2/strongSwan migration.<br />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!</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=171812015-02-05T13:14:31ZJan-Hendrik Wittkeinfo@j-hmw.de
<ul></ul><p>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.<br />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!!!</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=173592015-02-16T20:50:01ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Confirmed</i></li><li><strong>Assignee</strong> set to <i>Ermal Luçi</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Very High</i></li><li><strong>Target version</strong> set to <i>2.2.1</i></li></ul><p>Found a scenario where this is replicable with PPPoE.</p>
<p>1) setup IPsec bound to a PPPoE WAN, with no keepalive defined and nothing running in the background that will trigger the connection<br />2) bring the system up on a clean boot, go to Status>Interfaces and disconnect the PPPoE. Then reconnect it. <br />3) initiate some traffic that triggers the IPsec connection to come up.</p>
<p>It'll end up with logs along the lines of the following: <br /><pre>
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)
</pre></p>
<p>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.</p>
<p>In this specific circumstance, strongswan shows it's seeing the interface events. <br /><pre>
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
</pre></p>
<p>and 'ipsec statusall' shows the pppoe1 IP missing from "Listening IP addresses". <br /><pre>
Listening IP addresses:
198.51.100.77
</pre></p>
<p>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.</p>
<pre>
Listening IP addresses:
198.51.100.77
203.0.113.77
</pre> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=173602015-02-16T21:17:37ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Subject</strong> changed from <i>IPsec does not reconnect after WAN reconnect</i> to <i>strongSwan fails to re-attach dynamic IPs where interfaces_use specified</i></li></ul><p>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.</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=173942015-02-18T11:44:14ZSam BernardSammybernard@gmail.com
<ul></ul><p>Chris, will you merge BUG <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: IPSEC /Strongswan Fails to Detect IP address Change (Closed)" href="https://redmine.pfsense.org/issues/4425">#4425</a> 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 <a class="external" href="https://forum.pfsense.org/index.php?topic=87636.msg482884#msg482884">https://forum.pfsense.org/index.php?topic=87636.msg482884#msg482884</a>. I have provided logs on there too if you guys need for testing.</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=177022015-03-10T17:13:57ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Assignee</strong> changed from <i>Ermal Luçi</i> to <i>Chris Buechler</i></li></ul><p>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.</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=177032015-03-10T17:18:42ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Confirmed</i> to <i>Feedback</i></li></ul> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=177062015-03-10T19:19:38ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>fixed</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=177302015-03-11T08:33:42ZSam BernardSammybernard@gmail.com
<ul></ul><p>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.</p>
<p>SAM</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=177312015-03-11T08:46:42ZRenato Botelhorenato@netgate.com
<ul></ul><p>Sam Bernard wrote:</p>
<blockquote>
<p>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.</p>
<p>SAM</p>
</blockquote>
<p>You can get 2.2.1 snapshots or apply the patch from <a class="external" href="https://github.com/pfsense/pfsense/commit/eb6495c3b1dfdd3639a01bb27e7bf2285f9ae2ce">https://github.com/pfsense/pfsense/commit/eb6495c3b1dfdd3639a01bb27e7bf2285f9ae2ce</a> on 2.2</p> pfSense - Bug #4341: strongSwan fails to re-attach dynamic IPs where interfaces_use specifiedhttps://redmine.pfsense.org/issues/4341?journal_id=178032015-03-16T17:12:23ZSam BernardSammybernard@gmail.com
<ul></ul><p>Tried with the patch.. still does NOT work. Charon still does not re-establish the IPsec connections on PPPoE</p>