[strongSwan] Packet reordering problems

[Steffen Heil (Mailinglisten)]

Hi


We are currently in the process of switching from racoon to strongswan.
In a pure test scenario our approach works as expected, but in our production site, we have lots of network components between the two endpoints.
As a result packets may get reordered and we need to deal with that.

Interestingly we never observed such problems with racoon, which is a bit odd, since the IKE daemon cannot control the network routing...
Note: We plan to switch to strongswan on both sides, but for now, we can only modify the responder (central), not the initiators (lots of distributed workstations).

What we see is the following:
In phase 1 / Identity Protection (Main Mode):
The client/initiator sends a packet (A) to the responder which replies (B).
The client sends the next packet (C) and the responder replies again (D).
These 4 packets are not fragmented and the respective recipient has to wait for the packet, so no reordering can take place.
Then the client sends a packet (E) that is too big and gets IP fragmented.
The responder also replies with a big packet (F) that also gets fragmented.
(To my understanding, that completes phase 1).
Next, the responder sends a small "Transaction (Config Mode)" packet (G) to the client.
...

That all works perfectly, as long as the packets arrive in the order they were sent:
(left=initiator (always raccoon 0.8.0), right=responder (strongswan 5.1.1))

-> A
B <-
-> C
D <-
-> E1
-> E2
F1 <-
F2 <-
G <-
...

The problem is, that this order is only observable in about 40% if our tests.
In the other cases the packet order seems correct (on the responder side) but arrive incorrectly on the initiator side:

-> A
B <-
-> C
D <-
-> E1
-> E2
F1 <-
G <-
F2 <-
...

Then the problem is, that racoon gets the packet G before the IP stack is able to reconstruct F from F1 and F2 and raccoon cannot proceed with IKE.
We tried to prevent IP fragmentation by enabling IKE fragmentation in strongswan. That resulted in a following situation as observed on the responder:

-> A
B <-
-> C
D <-
-> E1
-> E2
F1 <-
F2 <-
F3 <-
G <-
...

But in about 40% of the time to the following on the initiator:

-> A
B <-
-> C
D <-
-> E1
-> E2
F1 <-
F2 <-
G <-
F3 <-
...

Thus, not solving the problem.


Now we reverted to raccoon 0.8.0.on the responder (as a temporary fix). Now the situation changed:

-> A
B <-
-> C
D <-
-> E1
-> E2
F1 <-
F2 <-
F3 <-
F4 <-
G <-
...

Interestingly we did not see any packet reordering and thus did not have any problems.
Looking more closely at the ike-fragmented packets in wireshark revealed different packet lengths:

Strongswan: F1=590, F2=590, F3=566, G1=138
Racoon: F1=594, F2=594, F3=594, F4=110, G=138


Currently we have no idea what to do.
We cannot change the infrastructure.


Our questions:
- Is there anything we can to do improve our situation?
- Does someone have experience with IKE and packet reordering?
- Is there any reasonable explanation, why raccoons packets don't get reordered? (As far as observed.)
- Will strongswan be able to handle reordering once we are able to deploy strongswan to the client?
- Any hints?


We might be able to offer pcap files of both sides...


Best regards,
   Steffen