On Thu, 26 May 2016, Tom Robinson wrote:
I've analysed the packets for both connections (remember; one connection is old
and works and the
other is new and fails).
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.
So the 3 IKE packets containing fragments is re-assembled but then
dropped? Can you run with plutodebug=all, and show the logs from the
moment you see "Received xxxx bytes from aa.bb.cc.dd" for the first
packet containing an IKE fragment.
This packet gets fragmented as before. After packet reassembly, the server then
responds with IKE_SA_INIT.
That might be a seperate bug. Some older versions of libreswan sending
errors with NOTIFY payloads mistakenly used IKE_INIT instead of
IKE_AUTH. So the fact that you see more IKE_AUTH packets might just
mean you are seeing the smae NOTIFY errors, but this time properly
replied to. Basically, an IKE_AUTH request may only result in an
IKE_AUTH answer and not an IKE_INIT answer.
It would be useful to see the plutodebug=all logs.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
