Project

General

Profile

Actions

Bug #4686

closed

Rekeyed SAs are not properly removed

Added by Florian Apolloner almost 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
IPsec
Target version:
Start date:
05/07/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:

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

Selection_001.png (147 KB) Selection_001.png Florian Apolloner, 05/07/2015 03:24 PM
child_sa.jpg (185 KB) child_sa.jpg Ivo B, 05/19/2015 02:42 AM
Actions #1

Updated by Phillip Davis almost 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).

Actions #2

Updated by Florian Apolloner almost 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.

Actions #3

Updated by Phillip Davis almost 9 years ago

Yeh, you might be right. I will leave it for more knowledgeable persons to comment further.

Actions #4

Updated by Florian Apolloner almost 9 years ago

The many phase 2 entries might be a result of: https://wiki.strongswan.org/issues/951

Actions #5

Updated by Florian Apolloner almost 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?

Actions #6

Updated by Florian Apolloner almost 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 :)

Actions #7

Updated by Ivo B almost 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.

Actions #8

Updated by Florian Apolloner almost 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…)

Actions #9

Updated by Florian Apolloner almost 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.

Actions #10

Updated by Florian Apolloner almost 9 years ago

I see that the first one is already integrated as of cbc1f411604e0d5f608439db7b4f16303b03dcf2. Mind adding the second one too :)

Actions #11

Updated by Ivo B almost 9 years ago

As of this morning I have weird chils SAs again. Attaching a file.

Actions #12

Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback

Patches are merged so you can test with latest snaps.

Actions #13

Updated by Chris Buechler almost 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
Actions #14

Updated by Chris Buechler almost 9 years ago

  • Assignee set to Chris Buechler
Actions #15

Updated by Florian Apolloner almost 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.

Actions #16

Updated by Ivo B almost 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.

Actions #17

Updated by Florian Apolloner almost 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.

Actions #18

Updated by Florian Apolloner almost 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?

Actions #19

Updated by Ermal Luçi almost 9 years ago

I corrected the patch to the one in FreeBSD.
Should be on newer snapshots.

Actions #20

Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Resolved

this is correct now in every circumstance I could previously replicate problems.

Actions #21

Updated by Ivo B over 8 years ago

I confirm.
All my pfsense boxes on latest 2.2.4 version.
IPsec tunnels working!

Thanks.

Actions

Also available in: Atom PDF