[Swan] Windows IKEv2 Error 809

[Paul Wouters]

On Wed, 1 Jun 2016, Tom Robinson wrote:

>> On the old connection the IKE_AUTH packet from the client gets fragmented into three and then
>> reassembled. It's 3296 bytes on reassembly. The server responds with IKE_AUTH and the connection
>> comes up without any further fragmentation. At this stage I see lots of ESP packets coming to and fro.
>>
>> On the new connection the IKE_AUTH progresses in the same way as for the old connection (packet from
>> the client gets fragmented into three and then reassembled. It's also 3296 bytes). The server
>> responds with IKE_AUTH four times but the client seems to ignore it and resends another IKE_AUTH
>> packet instead. This packet gets fragmented as before. After packet reassembly, the server then
>> responds with IKE_SA_INIT. The client seems to ignore this again and resends another fragmented
>> IKE_AUTH. The client gives up with "Error 809".
>>
>
> I'm still stumped by this.
>
> Can someone please clarify the 'fragmentation' setting wrt 'a size larger than 576 bytes' (from the
> man page)?

fragmentation=yes or force fragments IKE packets before they leave the
IKE daemon. In IKEv2, these fragments are seperately encrypted. In
IKEv1, it is just cut into pieces with an IKE header slapped on the
parts.

Both amount to the IKE daemon never sending packets that would be
fragmented by the OS or a router. The goal is to avoid that in case
the OS or routers on the path are dropping fragmented packets.

These fragments are around the minimum packet size (because once you
cut an +/- 1500 byte packet, you might as well cut them so it is not
close to any potential problematic size (eg 1200 when some ppp is used)

> I have a number of ISAKMP (IKE_AUTH) packets received on the client that have been fragmented and
> apparently ignored. There are four packets, three of which are 568 bytes, the last being 512 bytes.
> They are not being reassembled (according to wireshark) on the client. All four packets have the
> "don't fragment" flag set.

> Is the 'fragmentation=force' setting missing these packets due to their small size?

So if all these "fragmented packets" look like IKE packets from port 500
or 4500, it means the IKE daemon fragmented these. So from a networking
point of view (eg as seen by tcpdump) these are not "fragmented". These
are just small UDP packets. So any firewall/re-assmbling on the OS is
not triggered for these.

If the other end does not support IKE fragmentation (RFC-7383) then it
will not be able to make sense of these packets and drop them. The
fragmentation=yes option requires the peer to tell us via a NOTIFY
in the first (small and never fragmented) packet that it supports
this, or we do not use fragmentation. When setting fragmentation=force,
we send fragments even if the remote did not specify support for this
in their initial packet. This latter is mostly to workaround strange
network issues or broken support and should not be needed.
fragmentation=yes is the safe value to use, but force can be used to
do some extra tests to locate a problem.