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