[strongSwan] received retransmit of response with ID 0, but next request already sent

[Thomas Egerer]

Hi Axel,

On 10/22/2014 01:22 PM, Axel Zöllich wrote:
>
> Why is this negotiation drifting away? The retransmit (12:56:39) contains
> exactly the same data as the package from 12:56:36. (checked with wireshark)
>
>
> Oct 22 12:56:36 08[CFG] received stroke: initiate 'jung'
> Oct 22 12:56:36 09[IKE] <jung|122> initiating Main Mode IKE_SA jung[122] to
> 217.86.257.203
> Oct 22 12:56:36 09[ENC] <jung|122> generating ID_PROT request 0 [ SA V V V V ]
> Oct 22 12:56:36 09[NET] <jung|122> sending packet: from 80.152.262.292[500] to
> 217.86.257.203[500] (192 bytes)
> Oct 22 12:56:36 13[NET] <jung|122> received packet: from 217.86.257.203[500]
> to 80.152.262.292[500] (124 bytes)
> Oct 22 12:56:36 13[ENC] <jung|122> parsed ID_PROT response 0 [ SA V V ]
> Oct 22 12:56:36 13[IKE] <jung|122> received DPD vendor ID
> Oct 22 12:56:36 13[IKE] <jung|122> received NAT-T (RFC 3947) vendor ID
> Oct 22 12:56:36 13[ENC] <jung|122> generating ID_PROT request 0 [ KE No NAT-D
> NAT-D ]
> Oct 22 12:56:36 13[NET] <jung|122> sending packet: from 80.152.262.292[500] to
> 217.86.257.203[500] (372 bytes)
> Oct 22 12:56:36 07[NET] <jung|122> received packet: from 217.86.257.203[500]
> to 80.152.262.292[500] (356 bytes)
> Oct 22 12:56:36 07[ENC] <jung|122> parsed ID_PROT response 0 [ KE No NAT-D
> NAT-D ]
> Oct 22 12:56:36 07[ENC] <jung|122> generating ID_PROT request 0 [ ID HASH ]
> Oct 22 12:56:36 07[NET] <jung|122> sending packet: from 80.152.262.292[500] to
> 217.86.257.203[500] (68 bytes)
> Oct 22 12:56:39 07[NET] <jung|122> received packet: from 217.86.257.203[500]
> to 80.152.262.292[500] (356 bytes)
> Oct 22 12:56:39 07[IKE] <jung|122> received retransmit of response with ID 0,
> but next request already sent
> Oct 22 12:56:40 15[IKE] <jung|122> sending retransmit 1 of request message ID
> 0, seq 3
> Oct 22 12:56:40 15[NET] <jung|122> sending packet: from 80.152.262.292[500] to
> 217.86.257.203[500] (68 bytes)
> Oct 22 12:56:45 04[NET] <jung|122> received packet: from 217.86.257.203[500]
> to 80.152.262.292[500] (356 bytes)
> Oct 22 12:56:45 04[IKE] <jung|122> received retransmit of response with ID 0,
> but next request already sent
> Oct 22 12:56:47 07[IKE] <jung|122> sending retransmit 2 of request message ID
> 0, seq 3
> Oct 22 12:56:47 07[NET] <jung|122> sending packet: from 80.152.262.292[500] to
> 217.86.257.203[500] (68 bytes)
>
>
> strongswan 5.1.1
>
> conn jung
>         ikelifetime=86400
>         keylife=21600
>         keyingtries=20
>         esp=3des-sha1-modp2048
>         ike=3des-sha1-modp2048
>         left=80.152.262.292
>         leftsubnet=192.168.222.0/24
>         leftid=217.86.257.203
>         leftfirewall=yes
>         right=217.86.257.203
>         rightsubnet=192.168.1.0/24
>         rightid=%any
>         #auto=start
>         auto=route
>         #auto=add
Any chance you can provide the log information of the peer?
My best guess it that the peer doesn't like the third request
and retransmits the second response. Packet loss due to
fragmentation should not be a problem since the third request
is only 68 bytes in size. Also packet drops due to a firewall
with closed port 4500 is not an option.
Judging from your config, you are using public key
authentication. Do you see the certificates being transmitted?
Because this looks very much like an authentication gone wrong.
I've seen similar behavior before, the peer was an IKEv2 node
however.

Cheers,
Thomas