Hello Volker,

Sorry the previous message left out incomplete inadvertantly.

Thank you for your precious observations. Further to them I looked into the 
network MTUs to find out the threshold value the fragmentation occurs at.

From the GW at 192.168.4.87 :
C:\>ping -f -l 1470 192.168.4.10
works fine, no packet loss ever

The other side packets capture
[root@karma ~]# tcpdump -i eth0 -n -v -s 0 'host 192.168.4.87'
23:12:42.118481 IP (tos 0x0, ttl 128, id 16218, offset 0, flags [DF], proto: 
ICMP (1), length: 1498) 192.168.4.87 > 192.168.4.10: ICMP echo request, id 1, 
seq 20, length 1478
23:12:42.118556 IP (tos 0x0, ttl  64, id 62712, offset 0, flags [none], proto: 
ICMP (1), length: 1498) 192.168.4.10 > 192.168.4.87: ICMP echo reply, id 1, seq 
20, length 1478

C:\>ping -f -l 1475 192.168.4.10
Fragmentation required, but DF flag is set
Ping fails. ICMP unreachable


It could also be reproduced from the other karma's side:
[root@karma network-scripts]# ping -M do -s 1470 192.168.4.87
PING 192.168.4.87 (192.168.4.87) 1470(1498) bytes of data.
1478 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=2.42 ms
1478 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=2.67 ms

[root@karma network-scripts]# ping -M do -s 1475 192.168.4.87
From 192.168.4.10 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.4.10 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.4.10 icmp_seq=1 Frag needed and DF set (mtu = 1500)

If I understand it correctly, the fragmented packets are just dropped on the 
other host side and not reassembled correctly. This could be the reason the 
karma.host doesn't return the fragmented IKE_AUTH request packet.

Making the new search I knocked upon the message which could be a hint to 
resolving the issue:
 "Block Fragmented Packets" that is checked by default.  It seems that not only 
does this block regular WAN traffic that is fragmented, but also blocks traffic 
that is part of any IPSEC VPN tunnel.  Now that I know it, it seems like 
something I should have found, however, I would have thought that the firewall 
would not have blocked traffic within the tunnel.

Could the Fragemnted Packets be blocked by the linux host iptables? Do you have 
any knowledge how to enable fragmentation packet so that they could be 
reassembled?
There is no any particular MTU size setting on the linux host network card 
configuration and nothing restricts the packet size either as the network 
connection is over the local ethernet (for the testbed configuration and 
troubleshooting).

Regards,
Serge


> ----- Original Message -----
> From: Volker Rümelin
> Sent: 01/08/14 02:22 AM
> To: s s
> Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
> 
> Hello Serge,
> 
> tcpdump shows you still have a fragmentation problem. To show the 
> problem I copied the interesting parts from /var/log/messages and merged 
> them with the output from tcpdump.
> 
> > == the bt side =======
> > Jan 7 22:53:48 bt charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE 
> > No N(NATD_S_IP) N(NATD_D_IP) ]
> > Jan 7 22:53:48 bt charon: 16[NET] sending packet: from 10.0.2.15[500] to 
> > 192.168.4.10[500]
> > 22:53:48.558756 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP 
> > (17), length 728)
> > 10.0.2.15.500 > 192.168.4.10.500: isakmp 2.0 msgid 00000000: parent_sa 
> > ikev2_init[I]:
> > 22:53:48.818954 IP (tos 0x0, ttl 64, id 24, offset 0, flags [none], proto 
> > UDP (17), length 493)
> > 192.168.4.10.500 > 10.0.2.15.500: isakmp 2.0 msgid 00000000: parent_sa 
> > ikev2_init[R]:
> > Jan 7 22:53:48 bt charon: 17[NET] received packet: from 192.168.4.10[500] 
> > to 10.0.2.15[500]
> > Jan 7 22:53:48 bt charon: 17[ENC] parsed IKE_SA_INIT response 0 [ SA KE No 
> > N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
> 
> Below you can see the IKE_AUTH request going out as two fragments which 
> is not a problem.
> 
> > Jan 7 22:53:48 bt charon: 17[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 7 22:53:48 bt charon: 17[NET] sending packet: from 10.0.2.15[4500] to 
> > 192.168.4.10[4500]
> > 22:53:48.923237 IP (tos 0x0, ttl 64, id 49759, 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)
> > 22:53:48.923577 IP (tos 0x0, ttl 64, id 49759, offset 1480, flags [none], 
> > proto UDP (17), length 36)
> > 10.0.2.15 > 192.168.4.10: udp
> 
> But from karmas reply the second fragment is missing. flags [+]: more 
> fragments (MF)
> 
> > 22:53:49.033669 IP (tos 0x0, ttl 64, id 25, offset 0, flags [+], proto UDP 
> > (17), length 1500)
> > 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 same is true for the first and all following retransmits.
> 
> > Jan 7 22:53:52 bt charon: 08[IKE] retransmit 1 of request with message ID 1
> > Jan 7 22:53:52 bt charon: 08[NET] sending packet: from 10.0.2.15[4500] to 
> > 192.168.4.10[4500]
> > 22:53:52.943270 IP (tos 0x0, ttl 64, id 49760, 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)
> > 22:53:52.943605 IP (tos 0x0, ttl 64, id 49760, offset 1480, flags [none], 
> > proto UDP (17), length 36)
> > 10.0.2.15 > 192.168.4.10: udp
> > 22:53:52.949155 IP (tos 0x0, ttl 64, id 26, offset 0, flags [+], proto UDP 
> > (17), length 1500)
> > 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)
> >
> >
> 
> Here is what karmas reply should look like.
> 
> > ==== the karma side ===
> > 22:53:48.284443 IP (tos 0x0, ttl 64, id 17519, offset 0, flags [+], proto: 
> > UDP (17), length: 1500)
> > 192.168.4.10.ipsec-nat-t > 192.168.4.87.61579: NONESP-encap: isakmp 2.0 
> > msgid 00000001: child_sa ikev2_auth[]: [|v2e] (len mismatch: isakmp 1612/ip 
> > 1468)
> > 22:53:48.284468 IP (tos 0x0, ttl 64, id 17519, offset 1480, flags [none], 
> > proto: UDP (17), length: 164)
> > 192.168.4.10 > 192.168.4.87: udp
> 
> One way to solve this, is to store the certificates locally like you 
> already did. I can't see why this shouldn't work. Another way is to 
> change to ikev1 and enable fragmentation support. But you need 
> strongswan >= 5.0.2 on both sides. Please read about fragmentation 
> support and how to enable it in 
> http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection.
> 
> Both solutions don't help if you have a fragmentation problem with the 
> Windows 8 ikev2 VPN. I don't have Windows 8 available, but I know 
> Windows 7 sends CERTREQs for all CAs it knows. Windows sends this in 
> several fragments because of the amount of data. I assume it is the same 
> for Windows 8. I have a few patches for strongswan 5.1.1 which enable 
> fragmentation support with Windows ikev1 ipsec/l2tp VPN. But this is 
> unsupported code and only tested with Windows 7 and Windows XP.
> 
> And yes you are right. Try to solve the problems one by one.
> 
> Regards,
> Volker

_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to