[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
ipsec.config.
>> proposals 1:ESP:ENCR=AES_GCM_C_256;ESN=DISABLED[first-match]
>> 2:ESP:ENCR=AES_GCM_C_128;ESN=DISABLED
>> 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED
>> 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED
>> 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED
>> 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.
http://www.richmondnursery.com
More information about the Swan
mailing list