Bug #4129


IPsec connections with multiple P2s use only first SA

Added by Chris Buechler almost 7 years ago. Updated almost 7 years ago.

Very High
Ermal Luçi
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Where you have multiple P2s on a P1, only the first is actually used. The SPD and SAD are correct in setkey's output, but all outbound traffic on a given P1 ends up on the first SA. This breaks all the P2s other than the first. Can confirm via byte counters on SAs, and when testing with certain devices you'll get logs such as "the peer is sending other traffic through this security association" (from an ASA).


StrongSwan ipsec logs2.txt (19.9 KB) StrongSwan ipsec logs2.txt Logging from StrongSwan with 3 different tests Pi Ba, 12/20/2014 05:16 PM
Actions #1

Updated by Chris Buechler almost 7 years ago

probably the best next step, after discussion with Jim T earlier, is to try ipsec-tools on 2.2 and see if the issue persists. A test setup is in place, but not entirely functional. Setup is on racoon.conf, psk.txt, and spd.conf in /root/ there. racoon is via 'pkg install'. It seems to work fine when the other end initiates, but no traffic ever traverses the connection. I didn't change setkey, and I'm guessing that's where the issue is. I'm running short on time for today though. Ermal, please pick up on that. Unless you already know where the issue is and that won't help, then don't bother.

My suspicion is this seems like it's not a problem with strongswan at all, and this would help determine whether that's the case.

Actions #2

Updated by Pi Ba almost 7 years ago

To add a little info/reference here from report: #4112, with StrongSwan i was able to make it work in my situation by putting separate 'conn' sections in the config one for each P2. So it might not be required to add ipsec-tools to 2.2. If you guys think thats the better option that is ok for me. However it might be 'better' to use 1 piece of software if it supports everything required, and is only a 'configuration issue' which can be easily solved by writing a different config.

Actions #3

Updated by Pi Ba almost 7 years ago

I've been checking this a bit more, and did see that with the current way it does work properly for a tunnel that uses 'Cisco Unity'.. For the other P1 is only negotiated once, but does require multiple conn sections. Some 'anonymized' logging attached, with and without separate conn sections, with and without CISCO UNITY from the remote device.

Actions #4

Updated by Pi Ba almost 7 years ago

In my test above i created complete separate conn sections in the config file, it seems possible to not repeat all info by using 'also' like described here: [].

Actions #5

Updated by Ermal Luçi almost 7 years ago

  • Status changed from Confirmed to Feedback

Changes have been committed to generate single connections for each phase2 and confirmed by

Actions #6

Updated by Pi Ba almost 7 years ago

Tested, works ok for my tunnels. Thanks.

Actions #7

Updated by Chris Buechler almost 7 years ago

  • Status changed from Feedback to Resolved

this works. the only issue introduced by this that I've found is the status widget issue in #4164


Also available in: Atom PDF