Hello Serge, > Hello Volker, > My yesterday's conclusions regarding the networks MTU shortcomings were > probably wrong.
right, both your hosts work just fine. > I've looked into the MTU's issues and found ethernet compliant MTU 1500 from > both sides > 1500=1472+28 : > [root@karma ~]# ping -c 5 -M do -s 1472 192.168.4.87 > PING 192.168.4.87 (192.168.4.87) 1472(1500) bytes of data. > 1480 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=3.29 ms > 1480 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=8.03 ms > > Then to eliminate the the doubts I stopped down the iptbales and ran the same > root@bt:~# ipsec up karmaIKE2 > > What I found is (merging the log the way you did): > > root@bt:~# ipsec up karmaIKE2 > establishing CHILD_SA karmaIKE2 > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > Jan 10 23:27:53 bt charon: 10[IKE] establishing CHILD_SA karmaIKE2 > Jan 10 23:27:53 bt charon: 10[ENC] generating IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Jan 10 23:27:53 bt charon: 10[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > 23:27:53.426525 IP (tos 0x0, ttl 64, id 20103, offset 0, flags [+], proto UDP > (17), length 1500) > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > 00000001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > 23:27:53.427322 IP (tos 0x0, ttl 64, id 20103, offset 1480, flags [none], > proto UDP (17), length 36) > 10.0.2.15 > 192.168.4.10: udp > > > The Karma side reply: > 23:27:52.189035 IP (tos 0x0, ttl 63, id 7625, offset 0, flags [+], proto: > UDP (17), length: 1500) 192.168.4.87.49325 > 192.168.4.10.ipsec-nat-t: > NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[I]: [|v2e] (len > mismatch: isakmp 1484/ip 1468) > 23:27:52.189057 IP (tos 0x0, ttl 63, id 7625, offset 1480, flags [none], > proto: UDP (17), length: 36) 192.168.4.87 > 192.168.4.10: udp > > meaning, that karma sends back 2 packet segments due to the fragemntation as > required > > But the bt receives only one of them: > 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid 00000001: > child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468) > > The second completing udp packet (without the header) is missing. Hence the > initial large packet could not be reassembled. > > What could drop the fragmented packets on their pathway? What could be > considered further? I still think it's your NAT router. Tcpdump shows you do NAT somewhere. > > Can another authentication method reduce the packet size? Could a PSK shared > key form a smaller sized packets? I think so. But why don't you store the certificates on both sides and tell strongswan not to send the certificates? > If a smaller packets authentication is possible, it would allow to > troubleshoot the issue. > > You also mentioned that strongswan >= 5.0.2 supports fragmentation for IKEv1. > Why IKEv1 only supports fragmentation and not IKEv2? Ikev1 and ikev2 are different protocols. It's only implemented for ikev1. For ikev2 there only exists a internet draft at the moment. http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05 > > Thanks again, > Serge > Regards, Volker _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
