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 [email protected] 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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
