pfSense

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).

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.

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

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

So upstream says, that you are using a somewhat invalid syntax for leftsubnet (I have binat selected), might that be causing any trouble?

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 :)

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.

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…)

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.

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

Sadly I cannot easily upgrade to a snapshot currently and test this, but will provide feedback as soon as 2.2.3 is released.

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.

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.

After reading it more carefully it looks as if:

ipsec_hard_sadb_expire.diff:                 if (sav->lft_c->usetime != 0)

@Ivo sure that the shared key is not caused by anything else? What is the strongswan version on the snapshot you used?

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

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

Thanks.