Bug #4686
closedRekeyed SAs are not properly removed
0%
Description
I am getting weird behaviour on some IPSec connections since 2.2.2. It looks as if CHILD_SA are not cleaned up which sometimes seems to break the connection completely (ie no traffic flow, but connection still seen as up by pfsense). I can imagine that this is a StrongSwan problem itself (ie due to the 5.3 upgrade), but I am not really sure which modifications pfsense did… Any ideas which loglevels to increase etc?
Files
Updated by Phillip Davis over 9 years ago
There are some changes coming for 2.2.3 like https://github.com/pfsense/pfsense/commit/afd0c1f2c9c46eaa8e496e98bea8a8e0887d504f and others around that time that now let Strongswan handle reqid itself rather than pfSense doing it "manually".
Perhaps 2.2.3-DEVELOPMENT snapshots would be good to try (of course that depends on what the production status is of your system, how annoying the current behavior is and your risk assessment).
Updated by Florian Apolloner over 9 years ago
From the looks of it this should only affect connections with multiple P2 entries defined, no? I am having a single subnet which is routed.
Updated by Phillip Davis over 9 years ago
Yeh, you might be right. I will leave it for more knowledgeable persons to comment further.
Updated by Florian Apolloner over 9 years ago
The many phase 2 entries might be a result of: https://wiki.strongswan.org/issues/951
Updated by Florian Apolloner over 9 years ago
So upstream says, that you are using a somewhat invalid syntax for leftsubnet (I have binat selected), might that be causing any trouble?
Updated by Florian Apolloner over 9 years ago
After looking at patch-ipsec_nat.diff in the pfsense-tools repo, does this patch do anything aside from making the statusall output prettier (well and maybe checking if the subnet is okay)? In the end I'd prefer if the webui could check the subnet and strongswan gets patched as little as possible :)
Updated by Ivo B about 9 years ago
Florian Apolloner wrote:
I am getting weird behaviour on some IPSec connections since 2.2.2. It looks as if CHILD_SA are not cleaned up which sometimes seems to break the connection completely (ie no traffic flow, but connection still seen as up by pfsense). I can imagine that this is a StrongSwan problem itself (ie due to the 5.3 upgrade), but I am not really sure which modifications pfsense did… Any ideas which loglevels to increase etc?
I'm experiencing similar difficulties. "(ie no traffic flow, but connection still seen as up by pfsense)"
I can confirm this issue/problem with my setup. (Trianle of 2x 2.2.2 and one 2.1.2 pfsense boxes). I can't attach a screenshot of multiple CHILD_SA at the moment since they got "deleted". I will attach as soon as they are created again. I had problems on 2.2.1 too just not as frequent. I can't confirm multiple "dead" CHILD_SA on 2.2.1 since I can't remember.
Let me also add that remote subnets are in public range. Legacy reasons. Perhaps a routing issue?
I believe OP also has Public IPs on remote subnets. We chated on IRC. Might be related or not.
Updated by Florian Apolloner about 9 years ago
Ivo B wrote:
Let me also add that remote subnets are in public range. Legacy reasons. Perhaps a routing issue?
I believe OP also has Public IPs on remote subnets. We chated on IRC. Might be related or not.
Jupp, public subnet on the remote side. And that one seems the only tunnel to be affected (but it also receives the most traffic, so dunno…)
Updated by Florian Apolloner about 9 years ago
Would it be possible to apply those two patches:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200282
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200283
to the next pfsense release? The code looks simple enough and might be worth a try, or is there a easy way I could rebuild the kernel and test them myself.
Updated by Florian Apolloner about 9 years ago
I see that the first one is already integrated as of cbc1f411604e0d5f608439db7b4f16303b03dcf2. Mind adding the second one too :)
Updated by Ivo B about 9 years ago
- File child_sa.jpg child_sa.jpg added
As of this morning I have weird chils SAs again. Attaching a file.
Updated by Ermal Luçi about 9 years ago
- Status changed from New to Feedback
Patches are merged so you can test with latest snaps.
Updated by Chris Buechler about 9 years ago
- Subject changed from IPSec issues since 2.2.2 to Rekeyed SAs are not properly removed
- Target version set to 2.2.3
- Affected Version changed from 2.2.2 to 2.2.x
Updated by Florian Apolloner about 9 years ago
Sadly I cannot easily upgrade to a snapshot currently and test this, but will provide feedback as soon as 2.2.3 is released.
Updated by Ivo B about 9 years ago
Tried with this image:
pfSense-2.2.3-DEVELOPMENT-1g-amd64-nanobsd-upgrade-20150521-0706.img.gz
It broke IPsec connection completely. I'm getting "charon: 12[IKE] <con2000|36> no shared key found for ..." message.
Updated by Florian Apolloner about 9 years ago
Mhm, to be honest, the diff looks quite different from what upstream has, not sure if there was an error during copying the patch from upstream or if there are different codepaths in the different freebsd versions.
Updated by Florian Apolloner about 9 years ago
After reading it more carefully it looks as if:
ipsec_hard_sadb_expire.diff: if (sav->lft_c->usetime != 0)
should/could also get removed as per https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156875&action=diff
@Ivo sure that the shared key is not caused by anything else? What is the strongswan version on the snapshot you used?
Updated by Ermal Luçi about 9 years ago
I corrected the patch to the one in FreeBSD.
Should be on newer snapshots.
Updated by Chris Buechler about 9 years ago
- Status changed from Feedback to Resolved
this is correct now in every circumstance I could previously replicate problems.
Updated by Ivo B almost 9 years ago
I confirm.
All my pfsense boxes on latest 2.2.4 version.
IPsec tunnels working!
Thanks.