[Swan] IKEv2 causing netlink errors

Peter Rofner profner at richmondnursery.com
Tue Dec 10 22:40:04 UTC 2019

On 12/10/19 2:58 PM, Paul Wouters wrote:

>> Dec 10 07:04:14 [pluto] "Richmond_Home" #1: initiating v2 parent SA
>> Dec 10 07:04:14 [pluto] "Richmond_Home" #2: IKE SA authentication 
>> request rejected by peer: AUTHENTICATION_FAILED
> Do you have a log of the peer for this? Only that end knows why it
> rejected this.

Here's what I see on the peer end at that point:

Dec 10 17:03:27 [pluto] "Richmond_Home" #2: ERROR: asynchronous network 
error report on eno2 (sport=500) for message to x.x.x.x port 500, 
complainant x.x.x.x: Connection refused [errno 111, origin ICMP type 3 
code 3 (not authenticated)]
Dec 10 17:03:28 [pluto] "Richmond_Home" #2: STATE_PARENT_I1: 
retransmission; will wait 0.5 seconds for response

It repeats the re-transmission a few times, then re-starts the loop of 
the same error. Other than that, nothing else out of the ordinary or 
anything specific to authentication.

>> Dec 10 07:04:21 [pluto] "Richmond_Home" #3: processing IKE_SA_INIT 
>> request: SA,KE,Ni,N,N,N (message arrived 0 seconds ago)
> Interestingly, while this end's attempt is failing, the other end is
> starting its own attempt to this end.
>> Dec 10 07:04:21 [pluto] "Richmond_Home" #3: Authenticated using 
>> authby=secret
> Which seems to succeed here.

OK, so that sort of makes sense since both ends have auto=start in 

>> proposals 1:ESP:ENCR=AES_GCM_C_256;ESN=DISABLED[first-match] 
>> Dec 10 07:04:21 [pluto] "Richmond_Home" #3: ERROR: netlink response 
>> for Add SA esp.8b6ef1d5 at x.x.x.x included errno 38: Function not 
>> implemented
> It negotiated AES_GCM_C wit 256bit key with no ESN. Which should be fine
> and be accepted by the kernel. yet it is not? Very strange.

I'm wondering if there's something with the way that encryption 
algorithm is compiled in an Atom-specfic kernel? In the kernel, all the 
cryptography settings on both ends match, other that things like AVX and 
NI instructions which the Atom lacks.

>> And the log when ikev2=no returned to the ipsec.conf file and the 
>> connection establishes:
>> Dec 10 07:09:18 [pluto] "Richmond_Home" #2: STATE_QUICK_I2: sent QI2, 
>> IPsec SA established tunnel mode {ESP=>0x21824963 <0x4640938b 
>> xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=none DPD=passive}
> And here it installed AES-CBC with a 128 bit key and sha1.
> So in theory, it could be that your kernel does not support AES_GCM. It
> would be weird but consistent with the logs. But it still does not
> answer why the authentication failed for IKEv2. For that we need to see
> the logs of that remote server.

That's somewhat what I was leaning towards. CONFIG_CRYPTO_AES_X86_64 is 
set in the kernel on both ends. Or is there a different kernel config 
needed for AES-GCM? Nothing pops out at me. Regardless, I don't quite 
understand why the error only happens on one end. The peer of this 
machine has two other IPSec connections and doesn't error out with 
nearly the same settings.

>> One other difference between this connection and others my server is 
>> connecting to is this endpoint has a dynamic gateway so I can't add a 
>> static rightnexthop while all the other connections are fully static. 
>> Not sure if that's an influence or not.
> It could also lead to selecting a different (wrong?) PSK if you have
> multiple different ones. Setting leftid/rightid explicitely and not
> depending on the IP address as ID might stabilize that better.

The left= and right= are both static IP's on each end. Only on one end, 
the nexthop is omitted because it uses a dynamic gateway while the peer 
is static. I wouldn't expect it to select the wrong PSK because of that. 
That, and I don't get why it would only happen with IKEv2.

Peter Rofner
Richmond Nursery Inc.

More information about the Swan mailing list