[strongSwan] Packet reordering problems

Steffen Heil (Mailinglisten) lists at steffen-heil.de
Fri Apr 11 13:23:28 CEST 2014


> Is my assumption correct that you are initiating Main Mode, followed by a transaction request (Mode Config exchange in Push Mode or XAuth)? Is G the TRANSACTION request?

Absolutely correct.

> If yes: The problem arises from that fact that once strongSwan completes Main Mode, it immediately starts with the transaction request. In a network with some hops the transaction request might arrive before the last Main Mode message.

Thats exactly our interpretation.

> strongSwan queues up transaction requests and processes them once Main Mode is complete, ...

VERY GOOD to hear. This means that as soon as we switch to strongswan on the initiator, our problems will probably be gone.

> So I see the following options:
> * Switch to Mode Config Pull when using Push (and no XAuth)

How would we do that?
To be fair, so far we thought Mode Config was Push only?
The problem will be that we will probably need to change configuration options in the client, don't we?
We cannot touch the client...

> * Disable XAuth when using it

We need to support our racoon installations and therefor require xauth.

> * Make strongSwan "delay" the transaction request

That is was we were thinking about.
Yet, we thought about adding a delay using traffic control in the linux network stack....
In fact, on the strongswan side, we use xauth_noauth ...

> While it depends on your network what an appropriate delay is, it might be the most practical approach.
> charon has some useful strongswan.conf options for such things, namely charon.send_delay and charon.send_delay_type, see [1]. To delay sending of transaction requests, you could use something like:
> charon {
>   # delay in ms
>   send_delay = 50
>   # delay TRANSACTION messages only
>   send_delay_type = 6
> }

Very cool. Thanks a lot.
We are experimenting with this and we will report our results.

Best regards,

More information about the Users mailing list