Hello Volker, I tried "fragmentation=yes" before, but in specific connection section, not in %default, and it didn't make any effect. Now in %default section it solved my problem. Now I have enough evidence and knowledge to troubleshoot network together with hoster tech support. Thanks a lot !
01.03.2015, 19:17, "Volker Rümelin" <vr_strongs...@t-online.de>: > Hi Denis, >> Hello, >> >> my previous suggestion was wrong. I've compared tcpdumps on working and >> non-working hosts again, and found that in broken case client continues to >> re-send this packed to server: >> >> 19:53:09.673551 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto UDP >> (17), length 1212) >> 93.74.135.165.4500 > 179.179.179.179.4500: [udp sum ok] NONESP-encap: >> isakmp 1.0 msgid 00000000 cookie 7c7f3d5d2c5f466b->5121f3fa3093c391: phase 1 >> I ident[E]: [encrypted id] >> 19:53:09.673935 IP (tos 0x0, ttl 64, id 28340, offset 0, flags [+], proto >> UDP (17), length 1500) >> 179.179.179.179.4500 > 93.74.135.165.4500: NONESP-encap: isakmp 1.0 >> msgid 00000000 cookie 7c7f3d5d2c5f466b->5121f3fa3093c391: phase 1 R >> ident[E]: [encrypted id] (len mismatch: isakmp 1660/ip 1468) > > you have a network problem. As you can see from the flags [+] this is > the first fragment of a UDP message. The following fragment is missing. > A router or firewall dropped it on route to your server. >> 14:44:12.274524 IP 179.179.179.179.4500 > 46.211.137.122.43918: >> NONESP-encap: isakmp: phase 1 R ident[E] >> 14:44:12.274536 IP 179.179.179.179 > 46.211.137.122: ip-proto-17 > > The second packet from your working example is the fragment you are missing. > > If fixing your network problem is not an option, you can try if > fragmentation=yes in the conn %default section in ipsec.conf helps. > > Regards, > Volker _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
