[Swan] IKEv2 causing netlink errors

[Paul Wouters]

On Tue, 10 Dec 2019, Peter Rofner wrote:

> Here are some logs I have. Hopefully this works and provides some clues.
>
> This is where I commented out ikev2=no and the connection fails:

> 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.

> 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.

> 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.

> And the log when ikev2=no returned to the ipsec.conf file and the connection 
> establishes:

> Dec 10 07:09:17 [pluto] "Richmond_Home" #1: initiating Main Mode

> Dec 10 07:09:17 [pluto] "Richmond_Home" #1: STATE_MAIN_I4: ISAKMP SA 
> established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 
> group=MODP2048}

authentication passed.

> 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.

> 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.

Paul