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 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
