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

[Volker Rümelin]

Hello Serge,

> Hello Volker,
> My yesterday's conclusions regarding the networks MTU shortcomings were probably wrong.

right, both your hosts work just fine.

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

I still think it's your NAT router. Tcpdump shows you do NAT somewhere.

>
> Can another authentication method reduce the packet size? Could a PSK shared key form a smaller sized packets?

I think so. But why don't you store the certificates on both sides and 
tell strongswan not to send the certificates?

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

Ikev1 and ikev2 are different protocols. It's only implemented for 
ikev1. For ikev2 there only exists a internet draft at the moment.
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05

>
> Thanks again,
> Serge
>

Regards,
Volker