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.
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
