[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

[s s]

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 at 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 at 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 at 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