[Swan] Connection stops after STATE_PARENT_R1

[Paul Wouters]

On Sun, 9 Feb 2020, John Crisp wrote:

> All working perfectly and then suddenly it doesn't, and I don't get why.
>
> My ipsec configs are 'templated' so barring the cert name, right IP, and
> subnet, the settings are all identical. Saves mistakes.... !
>
> Two connections from two Endian boxes (using strongswan I think) to one
> Libreswan 3.29 server except for the incoming (right) IP address,
> rightsubnet and cert.
>
> One Endian works, one doesn't (it did). Tried restarting server,
> restarting router etc etc and nothing!
>
> I had been messing about with some L2TPD stuff, but have disabled all
> that and gone back to the start, but still stuck.
>
> The one that has stopped working gets this far on the Libre end, and
> then Libre just stops:
>
>  STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2
> cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
>
> It never seems to get this which is the next part in a working connection:
>
>   processing IKE_SA_INIT request: SA,KE,Ni,N,N,N (message arrived 0
> seconds ago)

odd.

> conn TestToHomeVoip
>     type=tunnel
>     authby=rsasig
>     leftrsasigkey=%cert
>     rightrsasigkey=%cert
>     leftcert="TestServerHomeClient"
>     rightcert="endian.ip"
>     auto=add
>     ikev2=insist
>     ike=aes256-sha2;dh14
>     phase2alg=aes256-sha2;dh14
>     encapsulation=no

Are you sure there is no NAT. Can you leave out encapsulation=no ?

> Feb  8 17:53:16.697419: "TestToHomeVoip" #9: STATE_PARENT_R1: received
> v2I1, sent v2R1 {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128
> prf=HMAC_SHA2_256 group=MODP2048}
> Feb  8 17:56:01.936284: "TestToHomeVoip" #9: received duplicate
> IKE_SA_INIT message request (Message ID 0); retransmitting response

Looks like libreswan's IKE_SA_INIT reply is not received by the other end,
which retransmits it's IKE_SA_INIT request. Check firewall settings?

> Feb  8 17:53:16 efw ipsec: 14[ENC] generating IKE_SA_INIT request 0 [ SA
> KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
> Feb  8 17:53:16 efw ipsec: 14[NET] sending packet: from endian.ip[500]
> to libre.ip[500] (684 bytes)
> Feb  8 17:53:16 efw ipsec: 07[NET] received packet: from libre.ip[500]
> to endian.ip[500] (465 bytes)
> Feb  8 17:53:16 efw ipsec: 07[ENC] parsed IKE_SA_INIT response 0 [ SA KE
> No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]

Oh, it did receive the packet.... that it is mandatory for it to reply!

> Feb  8 17:53:16 efw ipsec: 07[ENC] generating IKE_AUTH request 1 [ IDi
> CERT N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP)
> N(ADD_4_ADDR) N(ADD_4_ADDR) N(EAP_ONLY) ]
> Feb  8 17:53:16 efw ipsec: 07[NET] sending packet: from endian.ip[4500]
> to libre.ip[4500] (1504 bytes)

Hmm why did it not use fragmentation? It sent 1504 bytes, so it might be
that the UDP packet got truncated to 1500 and the fragment of 4 bytes
was dropped by a firewall.

> Feb  8 17:53:20 efw ipsec: 09[IKE] retransmit 1 of request with message ID 1
> Feb  8 17:53:20 efw ipsec: 09[NET] sending packet: from endian.ip[4500]
> to libre.ip[4500] (1504 bytes)

> 18:43:49.451604 IP (tos 0x20, ttl 53, id 10512, offset 0, flags [+],
> proto UDP (17), length 1492)
>     endian.ip.4500 > libre.ip.4500: NONESP-encap: isakmp 2.0 msgid
> 00000001: child_sa  ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1504/ip
> 1460)

See "len mismatch" ? It seems your MTU is 1460 but your packet is 1504.
Strongswan should really be triggering fragmentation here. Try and look
into their documentation to confirm how to enable IKEv2 fragmentation.

Paul