Project

General

Profile

Bug #8472

IPsec with "Split connections" enabled (multiple P2's) - new added P2's are not coming up (between two pfsense's 2.4.3)

Added by Vladimir Lind about 1 year ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
VPN
Target version:
Start date:
04/19/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.3
Affected Architecture:

Description

When a new P2 is created it is not appearing in active SA's.

For example - P2 is added for 10.200.136.0/24|/0 === 10.201.138.0/23|/0

It is somehow "intercepted" by 10.200.138.0/23|/0 === 10.201.138.0/23|/0 though 10.200.138.0/23 doesn't overlap with 10.200.136.0/24:

con1008: child: 10.200.136.0/24|/0 === 10.201.138.0/23|/0 TUNNEL, dpdaction=restart
con1008{6421}: ROUTED, TUNNEL, reqid 15
con1008{6421}: 10.200.136.0/24|/0 === 10.201.138.0/23|/0

con1008{6383}: INSTALLED, TUNNEL, reqid 15, ESP in UDP SPIs: ce81bb5b_i c31e54e7_o
con1008{6383}: AES_CBC_256/HMAC_SHA2_256_128/MODP_1024, 38448 bytes_i (208 pkts, 10s ago), 48680 bytes_o (206 pkts, 10s ago), rekeying in 29 minutes
con1008{6383}: 10.200.138.0/23|/0 === 10.201.138.0/23|/0

When deleting P2 for 10.200.138.0/23|/0 === 10.201.138.0/23|/0 and creating it again - either P2's for 10.200.138.0/23 and 10.200.136.0/24 are "intercepting" by another third P2.

Disabling "Split connections" workarounds it.

status_output (49).tgz (737 KB) status_output (49).tgz Vladimir Lind, 04/19/2018 11:08 AM

History

#1 Updated by Steve Beaver 9 months ago

  • Assignee set to Jim Pingle

#2 Updated by Jim Pingle 9 months ago

  • Assignee deleted (Jim Pingle)
  • Target version changed from 2.4.4 to 48

I can sort of reproduce this but not exactly in the way described. For example, if you stop and start (not restart) IPsec then both P2s work. This seems more like a different bug than described. The logs on the initiator side showed that it was making a proper request, the far side said the traffic selectors were unacceptable even though they did show in . After a stop/start it was all working, though. Comparing ipsec statusall output the specifications are identical in both cases but after a stop/start they both are established.

This may just be a side effect of using split tunnel in this way and what strongSwan needs to do to reload the configuration properly with this style. A basic reload may not be enough. We can revisit this in the future, but for now, if it's pfSense to pfSense, don't use split tunnel, and if you must, then stop and restart IPsec after adding P2 entries.

#3 Updated by Jim Pingle 2 months ago

  • Target version changed from 48 to 2.5.0

Also available in: Atom PDF