Re: IPSEC: tunnel breakage with out-of-order IPv4 fragments

[Steffen Klassert <steffen.klassert@secunet.com>]

On Mon, Jul 14, 2014 at 07:52:23AM -0400, Karl Heiss wrote:
> On Mon, Jul 14, 2014 at 5:33 AM, Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> >
> > Your tcpdump looks interesting. Is it possible that all your
> > fragmented packets have the id field set to 'id 0'? This should
> > be only the case if the DF flag is set on that packet, but this
> > is apparently not the case here. If all the fragmented packets
> > have id 0, it is not possible to determine the correct fragment
> > chain. If only one fragment gets lost, all further packets might
> > be reassembled wrong.
> >
> 
> Yes, all fragments have 'id 0'.
> 
> > When looking at the code, is seems that sctp sets the DF flag
> > on packets as the default. The IPsec encapsulation code copies
> > the DF bit from the inner header and sets 'id 0' in this case.
> > A first guess would be that someone removes the DF flag after
> > the IPsec encapsulation.
> >
> > Is the DF flag set on your inner sctp packets?
> >
> 
> Yes, the inner packets have DF set, but the outer do not.

So we need to find where the DF flag disappears.

I tried to reproduce your issue with the current net tree,
but I was not able to do so.

With the plain net tree, all packets have the DF flag set
(sctp and esp), no fragments.

With the net tree and commit c08751c851b78514f6ec5 reverted,
I have some packets with the DF flag and some without. The
packets without the DF flag got fragmented after IPsec
processing. But even in this case, the ESP packet has the
DF flag set whenever the inner sctp packet has it set.
And also, the DF flag is set whenever a packet has 'id 0'.
The fragmented packets never have the 'id 0'.

Can you describe your usecase more precisely? Do you use
any additional tunnel like ipip/gre etc. or packet mangling?