[strongSwan] udp packet size

[Steffen Plotner]

Hi,

Strongswan 5.2.2 on linux (centos 6) IKEv2 configuration for windows clients I have the following problem:

Initiator sends IKE_SA_INIT
Server responds with IKE_SA_INIT
Initiator sends IKE_AUTH
Server responds with a fragmented IP packet of 1514 bytes (the MTU is 1500 on the outgoing interface).

I have determined using wireshark, that the fragment gets dropped by someone... if the client is behind Comcast link it works, and behind a roadrunner link it fails.

My more specific question is why is the outgoing UDP packet size greater than the MTU size on the interface?

I have tried to modify the charon.fragment_size and conn specific fragmentation settings and cannot get this modify the behavior. If we could get the UDP packet size to be below the MTU of the interface, that would help.

Steffen

_______________________________________________________________________________________________
Steffen Plotner Amherst College Tel [phone]
Systems/Network Administrator/Programmer PO BOX 5000 Fax [phone]
Systems & Networking Amherst, MA 01002-5000 ***@amherst.edu

[Martin Willi]

Hi Steffen,

Post by Steffen Plotner
Strongswan 5.2.2 on linux (centos 6) IKEv2 configuration for windows
My more specific question is why is the outgoing UDP packet size
greater than the MTU size on the interface?

In an IKE_AUTH response, the large part of the message is probably the
exchanged certificate. You may try to generate a smaller server
certificate (chain) so that this message fits in your MTU.

Post by Steffen Plotner
I have tried to modify the charon.fragment_size and conn specific
fragmentation settings and cannot get this modify the behavior.

IKEv2 fragmentation is a protocol extension (RFC 7383), and AFAIK it is
not supported in the Windows client. So you can't use it with these
clients, but have to try to avoid messages larger than your MTU to get
things working on such constrained networks.

Regards
Martin

[Fred]

Post by Martin Willi
IKEv2 fragmentation is a protocol extension (RFC 7383), and AFAIK it is
not supported in the Windows client. So you can't use it with these
clients, but have to try to avoid messages larger than your MTU to get
things working on such constrained networks.

I seem to keep running into exactly the same issues as other people at
more or less the same time. What a co-incidence! I was looking into
this late last night; here are my thoughts.

I have Windows Phone 8.1 working nicely against strongSwan over wired
networks and WiFi. but over 3G/HSDPA mobile data networks the same
working connection doesn't work. It fails in the ikev2 auth. A 1500 byte
packet is sent but is retransmitted many times before finally failing.
tcpdump shows flags [+] indicating fragmentation (offset is 0). I can
provide packet dumps on request if helpful. So something in the path
doesn't like the fragmentation.

I wanted to look into path MTU being the culprit but I wasn't able to
detect the lowest MTU in the path since the mobile device is firewalled
by the network operator. People also do block UDP fragments, so I looked
into trying to preload the certificates to minimise data size in the
exchange. This didn't work. Presumably the WP always requests the vpn
cert? Setting sendleftcert=never breaks the connection in any case. So I
then looked into the fragmentation=yes feature. It didn't work, or
rather I couldn't get it to work and packet captures showed the messages
were STILL being fragmented despite me setting strongSwan fragment_size.
I had a think about how this feature might work, and it dawned on me
that this feature would have to be supported at both endpoints for
reassembly at the other end (it was late!). Reading the relevant
section in the RFC confirmed this. Obviously there's no Microsoft
documentation about whether or not this feature is supported in their
VPN Reconnect client; but it appears not. Shame there's no strongSwan
app in the Windows Store ;-)

[Fred]

Post by Steffen Plotner
Hi,
Initiator sends IKE_SA_INIT
Server responds with IKE_SA_INIT
Initiator sends IKE_AUTH
Server responds with a fragmented IP packet of 1514 bytes (the MTU is 1500 on the outgoing interface).

Just an update. Using ECDSA means these large packets are no longer an
issue. Perhaps RSA is preferred from a security point of view; I don't
know. But certainly the smaller key footprint without having to reduce
the RSA keysize or use a short DN is maybe a good solution.

[Steffen Plotner]

Hi Fred,

-----Original Message-----

Post by Steffen Plotner
Hi,
Strongswan 5.2.2 on linux (centos 6) IKEv2 configuration for windows
Initiator sends IKE_SA_INIT
Server responds with IKE_SA_INIT
Initiator sends IKE_AUTH
Server responds with a fragmented IP packet of 1514 bytes (the MTU is

1500 on the outgoing interface).
Just an update. Using ECDSA means these large packets are no longer an
issue. Perhaps RSA is preferred from a security point of view; I don't
know. But certainly the smaller key footprint without having to reduce
the RSA keysize or use a short DN is maybe a good solution.

I actually did try the ECSDA cert and saw that the packet sizes are small enough to not fragment, but the Windows 7 client does not understand it. It ends up just hanging the connection process. I found a reference about that here:

https://www.mail-archive.com/***@lists.strongswan.org/msg04603.html

Steffen

[Fred]

Post by Steffen Plotner
I actually did try the ECSDA cert and saw that the packet sizes are
small enough to not fragment, but the Windows 7 client does not
understand it. It ends up just hanging the connection process. I

Odd. Works fine for me with VPN client in Windows 8.1/Windows Phone 8.1.