[Swan] Android 14 - IKEv2/IPSEC PSK

[Paul Wouters]

On Wed, 27 Mar 2024, antonio via Swan wrote:

> I’m trying to connect an android device using native vpn and libreswan version 5.0rc2,  it looks like a simple connection host - host/subnet but it
> doesn’t connect…  got the following log: 

Note that the logs provided do not yet indicate a problem.

> Mar 27 17:55:02.739193: "tunnel1"[1] 192.168.1.126 #1: proposal 2:IKE=AES_GCM_C_256-HMAC_SHA2_512-ECP_256 chosen from remote proposals1:IKE:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA2_512;PRF=
> HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[first-match]2:IKE:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048
> ;DH=MODP1536[better-match]
> Mar 27 17:55:02.739254: "tunnel1"[1] 192.168.1.126 #1: initiator guessed wrong keying material group (DH24); responding with INVALID_KE_PAYLOAD requesting
> DH19

Both ends allow DH19 but libreswan as responder does not allow DH24
(2048-bit MODP Group with 256-bit Prime Order Subgroup) Note that DH22-24
is a strange group and is best avoided (see also RFC8247). These groups
have not been vetted by the Cryptographic Community at large, and come
directly from NIST without peer review. These groups are therefor at best
"questionable" and libreswan does not add these to the default proposal
list. Why is the client preferring DH24? It's a very odd choice.

> Mar 27 17:55:02.739330: "tunnel1"[1] 192.168.1.126 #1: responding to IKE_SA_INIT message (ID 0) from 192.168.1.126:41943 with unencrypted notification
> INVALID_KE_PAYLOAD

This is the response, telling the initiator to retry with DH19 (ECP_256)

> Mar 27 17:55:02.739356: "tunnel1"[1] 192.168.1.126 #1: encountered fatal error in state STATE_V2_PARENT_R0
> Mar 27 17:55:02.739516: "tunnel1"[1] 192.168.1.126 #1: deleting IKE SA (processing IKE_SA_INIT request)
> Mar 27 17:55:02.739710: "tunnel1"[1] 192.168.1.126: deleting connection instance with peer 192.168.1.126

The connection is removed properly.

> Mar 27 17:55:02.750583: "tunnel1"[2] 192.168.1.126 #2: proposal 2:IKE=AES_GCM_C_256-HMAC_SHA2_512-ECP_256 chosen from remote proposals1:IKE:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA2_512;PRF=
> HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=ECP_256;DH=DH24;DH=ECP_384;DH=MODP2048;DH=MODP1536[first-match]2:IKE:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=ECP_256;DH=DH24;DH=ECP_384;DH=MODP2048
> ;DH=MODP1536[better-match]
> Mar 27 17:55:02.754631: "tunnel1"[2] 192.168.1.126 #2: processed IKE_SA_INIT request from 192.168.1.126:UDP/41943 {cipher=AES_GCM_16_256 integ=n/a
> prf=HMAC_SHA2_512 group=DH19}

The IKE SA established properly with DH19 now. But you show no further
log of the Child SA (IPsec SA) being established or not.

> My tunnel configuration:
> 
> conn tunnel1
> type=tunnel
> authby=secret
> auto=add
> left=192.168.1.10
> leftsubnet=192.168.10.0/24
> leftid=192.168.101.2
> keyingtries=3
> ikelifetime=8h
> salifetime=8h
> right=%any
> rightid=192.168.102.1

Nothing to fix, although I would remove keyingtries, ikelifetime and
salifetime and rely on our defaults.

Although it is unclear what your tunnel is for. If you want
192.168.102.1 to reach 192.168.10.0/24, you need to add
rightsubnet=192.168.102.1/32. Since you allow coming from "any"
and you appear to be NATed based on your rightid=, you should
configure the IP address that the client is going to use as
source IP.

> You can see pluto.log, debug = all here https://pastebin.com/4V26rLnw 

Based on those logs, it seems the client is trying to use EAP but you
have not configured libreswan to use EAP.

You should clarify what both ends want to use as authentication method
and configure them both to use that same method.

Paul