Project

General

Profile

Issue #1292

Incorrect SA status with IKEv2 tunnel carrying mixed IPv4 and IPv6 traffic

Added by Jim Pingle about 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
dr|rc|master
Resolution:
No feedback

Description

I noticed this in lab testing with a single IKEv2 tunnel that has both IPv4 and IPv6 traffic in a single connection, for example:

    rightsubnet = 10.7.0.0/24,2001:db8:1:deb0::/64
    leftsubnet = 192.168.43.0/24,2001:db8:1:eec0::/60

The output of "ipsec statusall" shows the correct pairings of networks under Routed Connections:

Routed Connections:
        con1{3}:  ROUTED, TUNNEL, reqid 1
        con1{3}:   192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0 === 10.7.0.0/24|/0 2001:db8:1:deb0::/64|/0

But under the Security Associations the output is incorrect:

Security Associations (1 up, 0 connecting):
        con1[1]: ESTABLISHED 28 minutes ago, 198.51.100.100[198.51.100.100]...198.51.100.7[198.51.100.7]
        con1[1]: IKEv2 SPIs: 77b4381031502095_i* 53b145c57a3f7c63_r, pre-shared key reauthentication in 7 hours
        con1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        con1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c205845b_i c0dbd04f_o
        con1{2}:  AES_CBC_256/HMAC_SHA1_96, 1456 bytes_i, 3680 bytes_o, rekeying in 17 minutes
        con1{2}:   192.168.43.0/24|/0 === 2001:db8:1:deb0::/64|/0

Note the last line that reports only one of the networks on the left and right, and not the ones using the same address family. I would expect the output to be identical to that shown in "Routed Connections" where all addresses from each side are listed.

The tunnel is up and traffic is passing as expected for both IPv4 and IPv6 hosts, so it is not apparently a fatal problem or adversely affecting traffic.

This is on a FreeBSD 10.3-PRERELEASE system (pfSense 2.3-BETA) using strongSwan 5.4.0dr4

Full output of "ipsec statusall" along with the strongswan.conf and ipsec.conf are in the attached file.

ipsec_status_bug.txt (4.01 KB) ipsec_status_bug.txt Jim Pingle, 01.02.2016 22:29

History

#1 Updated by Tobias Brunner about 4 years ago

  • Status changed from New to Feedback

I can't reproduce this. Are all traffic selectors listed in the "CHILD_SA ... established ..." log message? How does the config/log of the other peer look like? Maybe it narrows the subnets.

I guess due to the trap policies it's possible that traffic flows successfully even if no proper policies are negotiated and installed with the CHILD_SA.

#2 Updated by Jim Pingle about 4 years ago

The other end is a mirror image, config-wise. No narrowing, they match exactly:

    rightsubnet = 192.168.43.0/24,2001:db8:1:eec0::/60
    leftsubnet = 10.7.0.0/24,2001:db8:1:deb0::/64

Looking today after leaving them up overnight, the logs show yet a different set, but consistent:

Feb  2 10:06:39 jack charon: 10[IKE] <con1|3> CHILD_SA con1{29} established with SPIs cc4b04a6_i ce559d7a_o and TS 192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0 === 2001:db8:1:deb0::/64|/0
...
Feb  2 10:06:39 shona charon: 13[IKE] <con1|3> CHILD_SA con1{29} established with SPIs ce559d7a_i cc4b04a6_o and TS 2001:db8:1:deb0::/64|/0 === 192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0

And the SA status now matches the logs:

        con1{29}:   192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0 === 2001:db8:1:deb0::/64|/0

It's still missing the IPv4 network from the other end (10.7.0.0/24) and yet traffic continues to pass as expected.

I restarted both sides and then sent a ping and ping6 practically simultaneously to bring them up and then both appeared:

Feb  2 10:42:49 jack charon: 01[IKE] <con1|1> CHILD_SA con1{2} established with SPIs c2a6104e_i c231d572_o and TS 192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0 === 10.7.0.0/24|/0 2001:db8:1:deb0::/64|/0
[...]
        con1{2}:   192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0 === 10.7.0.0/24|/0 2001:db8:1:deb0::/64|/0
[...]
Feb  2 10:42:49 shona charon: 11[IKE] <con1|1> CHILD_SA con1{2} established with SPIs c231d572_i c2a6104e_o and TS 10.7.0.0/24|/0 2001:db8:1:deb0::/64|/0 === 192.168.43.0/24|/0 2001:db8:1:eec0::
[...]
        con1{2}:   10.7.0.0/24|/0 2001:db8:1:deb0::/64|/0 === 192.168.43.0/24|/0 2001:db8:1:eec0::/60|/0

Not sure what to make of it really, since things appear to be functional, though it makes viewing the tunnel status a bit confusing when it's mismatched.

#3 Updated by Tobias Brunner about 4 years ago

Looking today after leaving them up overnight, the logs show yet a different set, but consistent:

You might want to increase the log level for the cfg subsystem to 2 to see more details when the traffic selectors are negotiated (i.e. what TS each host proposes).

It's still missing the IPv4 network from the other end (10.7.0.0/24) and yet traffic continues to pass as expected.

As said earlier you already have policies installed for that subnet (due to auto=route) the hosts probably just use these.

Not sure what to make of it really, since things appear to be functional, though it makes viewing the tunnel status a bit confusing when it's mismatched.

Yes, seems strange. Especially that the subnets would show up in different combinations.

#4 Updated by Tobias Brunner almost 4 years ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No feedback

Also available in: Atom PDF