[Swan] IKEv2 connection from Android drops after a few minutes

Paul Wouters paul at nohats.ca
Wed Mar 11 19:29:52 UTC 2020


Your certificates are not properly generated, add require-id-on-certificate=no

Paul 

Sent from my iPhone

> On Mar 11, 2020, at 14:44, Beat Zahnd <beat.zahnd at gmail.com> wrote:
> 
> not working at all with 3.31 and unchanged config...
> 
> 
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x: local IKE proposals (IKE SA responder matching remote proposals): 
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x:   1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x:   2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x:   3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x:   4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x #1: proposal 2:IKE=AES_GCM_C_256-HMAC_SHA2_512-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_128;ENCR=AES_CBC_192;ENCR=AES_CBC_256;ENCR=3DES;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA1_96;INTEG=AES_XCBC_96;PRF=HMAC_SHA2_256;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_512;PRF=AES128_XCBC;PRF=HMAC_SHA1;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=BRAINPOOL_P256R1;DH=BRAINPOOL_P384R1;DH=BRAINPOOL_P512R1;DH=CURVE25519;DH=MODP3072;DH=MODP4096;DH=MODP6144;DH=MODP8192;DH=MODP2048[first-match] 2:IKE:ENCR=AES_GCM_C_128;ENCR=AES_GCM_C_192;ENCR=AES_GCM_C_256;ENCR=CHACHA20_POLY1305;ENCR=AES_GCM_B_128;ENCR=AES_GCM_B_192;ENCR=AES_GCM_B_256;ENCR=AES_GCM_A_128;ENCR=AES_GCM_A_192;ENCR=AES_GCM_A_256;PRF=HMAC_SHA2_256;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_512;PRF=AES128_XCBC;PRF=HMAC_SHA1;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=BRAINPOOL_P256R1;DH=BRAINPOOL_P384R1;DH=BRAINPOOL_P512R1;DH=CURVE25519;DH=MODP3072;DH=MODP4096;DH=MODP6144;DH=MODP8192;DH=MODP2048[better-match]
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x #1: initiator guessed wrong keying material group (ECP_256); responding with INVALID_KE_PAYLOAD requesting MODP2048
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x #1: responding to IKE_SA_INIT (34) message (Message ID 0) from 178.197.x.x:14272 with unencrypted notification INVALID_KE_PAYLOAD
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x #1: encountered fatal error in state STATE_PARENT_R0
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[1] 178.197.x.x #1: deleting state (STATE_PARENT_R0) aged 0.000s and NOT sending notification
> Mar 11 19:39:24 core pluto[8262]:  #1: deleting connection "ikev2-cp"[1] 178.197.x.x instance with peer 178.197.x.x {isakmp=#0/ipsec=#0}
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x: local IKE proposals (IKE SA responder matching remote proposals): 
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x:   1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x:   2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x:   3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x:   4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: proposal 2:IKE=AES_GCM_C_256-HMAC_SHA2_512-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_128;ENCR=AES_CBC_192;ENCR=AES_CBC_256;ENCR=3DES;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA1_96;INTEG=AES_XCBC_96;PRF=HMAC_SHA2_256;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_512;PRF=AES128_XCBC;PRF=HMAC_SHA1;DH=MODP2048;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=BRAINPOOL_P256R1;DH=BRAINPOOL_P384R1;DH=BRAINPOOL_P512R1;DH=CURVE25519;DH=MODP3072;DH=MODP4096;DH=MODP6144;DH=MODP8192[first-match] 2:IKE:ENCR=AES_GCM_C_128;ENCR=AES_GCM_C_192;ENCR=AES_GCM_C_256;ENCR=CHACHA20_POLY1305;ENCR=AES_GCM_B_128;ENCR=AES_GCM_B_192;ENCR=AES_GCM_B_256;ENCR=AES_GCM_A_128;ENCR=AES_GCM_A_192;ENCR=AES_GCM_A_256;PRF=HMAC_SHA2_256;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_512;PRF=AES128_XCBC;PRF=HMAC_SHA1;DH=MODP2048;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=BRAINPOOL_P256R1;DH=BRAINPOOL_P384R1;DH=BRAINPOOL_P512R1;DH=CURVE25519;DH=MODP3072;DH=MODP4096;DH=MODP6144;DH=MODP8192[better-match]
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: processing decrypted IKE_AUTH request: SK{IDi,CERT,N,CERTREQ,AUTH,CP,N,SA,TSi,TSr,N,N,N,N}
> Mar 11 19:39:24 core pluto[8262]: loading root certificate cache
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: certificate verified OK: CN=bz
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: certificate subjectAltName extension does not match ID_IPV4_ADDR '178.197.x.x'
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: Peer CERT payload SubjectAltName does not match peer ID for this connection
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: X509: connection failed due to unmatched IKE ID in certificate SAN
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[2] 178.197.x.x #2: switched from "ikev2-cp"[2] 178.197.x.x to "ikev2-cp"
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[3] 178.197.x.x #2: deleting connection "ikev2-cp"[2] 178.197.x.x instance with peer 178.197.x.x {isakmp=#0/ipsec=#0}
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[3] 178.197.x.x #2: IKEv2 mode peer ID is ID_DER_ASN1_DN: 'CN=bz'
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[3] 178.197.x.x #2: No acceptable ECDSA/RSA-PSS ASN.1 signature hash proposal included for rsasig in I2 Auth Payload
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[3] 178.197.x.x #2: responding to IKE_AUTH message (ID 1) from 178.197.x.x:41087 with encrypted notification AUTHENTICATION_FAILED
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[3] 178.197.x.x #2: encountered fatal error in state STATE_PARENT_R1
> Mar 11 19:39:24 core pluto[8262]: "ikev2-cp"[3] 178.197.x.x #2: deleting state (STATE_PARENT_R1) aged 0.513s and NOT sending notification
> Mar 11 19:39:24 core pluto[8262]:  #2: deleting connection "ikev2-cp"[3] 178.197.x.x instance with peer 178.197.x.x {isakmp=#0/ipsec=#0}
> 
> I will try older versions
> 
> 
>> On 11 Mar 2020, at 14:13, Paul Wouters <paul at nohats.ca> wrote:
>> 
>>> On Wed, 11 Mar 2020, Beat Zahnd wrote:
>>> 
>>> I run 3.27 which is last version on stable Debian.
>> 
>> Grab the 3.31 source and run "make deb" ?
>> 
>>> Are the NAT-T keepalives fully independent from the DPD keepalives?
>> 
>> Yes. There are completely unrelated. DPDs only happen when there is no
>> IPsec traffic. NAT keepalives always happen (Its cheaper to fire them
>> then to ask the kernel every 20s if there was traffic)
>> 
>> Paul



More information about the Swan mailing list