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

Volker Rümelin vr_strongswan at t-online.de
Wed Jan 8 02:22:03 CET 2014


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





More information about the Users mailing list