[Swan] IKEv2 + PSK to Android question

Paul Wouters paul at nohats.ca
Fri Apr 28 17:09:28 UTC 2017


It means your PSK's don't match.

Sent from my iPhone

> On Apr 28, 2017, at 13:06, Nick Howitt <nick at howitts.co.uk> wrote:
> 
> Hi Paul,
> 
> I've trying to set up a very basic IKEv2+PSK conn from Android 5.0.1 to libreswan 3.20 but it is giving errors:
> 
> conn test
> type=tunnel
> authby=secret
> auto=add
> left=82.19.158.192
> leftsourceip=172.17.2.1
> leftsubnet=172.17.2.0/24
> right=%any
> rightid=@nick
> salifetime=1h
> ikelifetime=8h
> ikev2=insist
> dpdaction=clear
> dpdtimeout=120
> dpddelay=30
> rekey=no
> 
> and:
> 
> Apr 28 17:58:13 server pluto[3953]: packet from 85.255.235.101:36533: test IKE proposals for initial responder: 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 (default)
> Apr 28 17:58:13 server pluto[3953]: packet from 85.255.235.101:36533: proposal 2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;DH=MODP2048 chosen from: 1: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]
> Apr 28 17:58:13 server pluto[3953]: packet from 85.255.235.101:36533: initiator guessed wrong keying material group (DH24); responding with INVALID_KE_PAYLOAD requesting MODP2048
> Apr 28 17:58:13 server pluto[3953]: packet from 85.255.235.101:36533: sending unencrypted notification v2N_INVALID_KE_PAYLOAD to 85.255.235.101:36533
> Apr 28 17:58:14 server pluto[3953]: packet from 85.255.235.101:36533: proposal 2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;DH=MODP2048 chosen from: 1: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]
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_512 group=MODP2048}
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: new NAT mapping for #455, was 85.255.235.101:36533, now 85.255.235.101:54219
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: IKEv2 mode peer ID is ID_FQDN: '@nick'
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: AUTH mismatch: Received AUTH != computed AUTH
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: PSK Authentication failed: AUTH mismatch!
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: sending unencrypted notification v2N_AUTHENTICATION_FAILED to 85.255.235.101:54219
> Apr 28 17:58:14 server pluto[3953]: | ikev2_parent_inI2outR2_tail returned STF_FATAL
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101 #455: deleting state (STATE_PARENT_R1)
> Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101: deleting connection "test"[4] 85.255.235.101 instance with peer 85.255.235.101 {isakmp=#0/ipsec=#0}
> Apr 28 17:58:15 server pluto[3953]: packet from 85.255.235.101:54219: sending unencrypted notification v2N_INVALID_IKE_SPI to 85.255.235.101:54219
> Apr 28 17:58:17 server pluto[3953]: packet from 85.255.235.101:54219: sending unencrypted notification v2N_INVALID_IKE_SPI to 85.255.235.101:54219
> Apr 28 17:58:20 server pluto[3953]: packet from 85.255.235.101:54219: sending unencrypted notification v2N_INVALID_IKE_SPI to 85.255.235.101:54219
> Apr 28 17:58:27 server pluto[3953]: packet from 85.255.235.101:54219: sending unencrypted notification v2N_INVALID_IKE_SPI to 85.255.235.101:54219
> Apr 28 17:58:37 server pluto[3953]: packet from 85.255.235.101:54219: sending unencrypted notification v2N_INVALID_IKE_SPI to 85.255.235.101:54219
> Apr 28 17:58:56 server pluto[3953]: packet from 85.255.235.101:54219: sending unencrypted notification v2N_INVALID_IKE_SPI to 85.255.235.101:54219
> 
> It looks like it has agreed a proposal but I've no idea about the AUTH mismatch. I know I have not configured an addresspool. Is it necessary and causing this issue or is there something else going on?
> 
> Regards,
> 
> Nick
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan



More information about the Swan mailing list