Why does this traffic selector not match?

Thanatos

8/3/24, 9:30 PM

(Note: I'm really using pfSense, but I'm just going to focus on the ipsec.conf files, since pfSense doesn't seem particularly relevant to the issue.)

We're getting the following error from charon:

Aug  2 21:10:10 vpn-left charon: 13[CFG] <con2000|2049> looking for a child config for 100.127.7.8/32|/0 === 100.127.6.8/32|/0
Aug  2 21:10:10 vpn-left charon: 13[IKE] <con2000|2049> traffic selectors 100.127.7.8/32|/0 === 100.127.6.8/32|/0 unacceptable
Aug  2 21:10:10 vpn-left charon: 13[IKE] <con2000|2049> failed to establish CHILD_SA, keeping IKE_SA
Aug  2 21:10:10 vpn-left charon: 13[ENC] <con2000|2049> generating CREATE_CHILD_SA response 131 [ N(TS_UNACCEPT) ]

The ipsec.conf that corresponds to this is:

conn con2000
    fragmentation = yes
    keyexchange = ikev2
    reauth = yes
    forceencaps = no
    mobike = no

    rekey = yes
    installpolicy = yes
    type = tunnel
    dpdaction = restart
    dpddelay = 10s
    dpdtimeout = 60s

    auto = route
    left = <snip>
    right = <snip>
    leftid = <snip>
    ikelifetime = 86400s
    lifetime = 3600s
    ike = aes256-sha256-modp2048!
    esp = aes256gcm128-sha256-modp2048!
    leftauth = psk
    rightauth = psk
    rightid = <snip>
    rightsubnet = 100.127.6.4,100.127.6.2,100.127.6.8,100.127.6.6
    leftsubnet = 100.127.7.4|10.10.0.66,100.127.7.2|10.10.0.0/16,100.127.7.8|10.10.0.67,100.127.7.6|10.10.0.0/16

In this setup I am left, and the org we're peering with is right. That is, local == left, remote == right, from my perspective.

This is attempting to set up 4 child SAs. We know the first and last ones, as listed in this configuration, to be working. The child SA that charon is failing to find here should be the third one in the list. If I snip out all the surrounding information, and swap the lines so that left comes first:

    # looking for […] 100.127.7.8/32|/0 === 100.127.6.8/32|/0
    leftsubnet = […],100.127.7.8|10.10.0.67,[…]
    rightsubnet = […],100.127.6.8,[…]

I'm starting to think I'm blind: that's an exact match … is it not? I'm not seeing why the incoming TS doesn't match that part of the configuration.

(What's doubly baffling to us is that the first child SA appears to work; it's basically the same configuration with slightly different IP addresses!)

0 + 2

freebsd

ipsec

pfsense

ecdsa

8/4/24, 10:34 AM

pfSense could be relevant as you are using that proprietary `|` syntax for traffic selectors that's not available in upstream strongSwan. Not sure if that's actually an issue here, though. Try increasing the log level for _cfg_ to see more about that child config lookup and traffic selector matching.

Thanatos

8/4/24, 9:24 PM

We reset the tunnel at the remote end, and now the TS appears to match. I'm not certain if the reset caused the TS they were sending to change, or the reset of the IKE SAs changed some local state that was no good, or what. (I did bump the suggesting logging to "Highest", but the logs foiled me. I was tailing them, but they are apparently ringbuffers.)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Why does this traffic selector not match?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.