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

Sat Jan 11 00:11:08 CET 2014

Hello Volker,
My yesterday's conclusions regarding the networks MTU shortcomings were probably wrong.
I've looked into the MTU's issues and found ethernet compliant MTU 1500 from both sides 
1500=1472+28 :
[root at 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 at bt:~# ipsec up karmaIKE2

What I found is (merging the log the way you did):

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

Can another authentication method reduce the packet size? Could a PSK shared key form a smaller sized packets?
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?

Thanks again,
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