IPSec tcp session stalling ( me too ) ...

[Volker]

Yvan,

as far as I'm not totally wrong on the MTU issue, I've already checked that.

On the other side, if it's an MTU issue, wouldn't the stream break at
the first oversized packet? I mean the scp session is sending around 56k
of data through the stream and then the session stalls. My gnetcat test
setup was able to get somewhat around 64k of data through the tunnel
before the session gets aborted.

>From my view if it's an MTU issue it has to stall when the first 2, 3 or
4 kByte have been transmitted. Am I wrong?

Also I already tried to play around with pf and set max-mss as low as
640 or 576 just for testing this. It didn't solve anything.

As written in my first post of this thread, the gifX interface already
has the lowest possible MTU (by default) of 1280. The underlaying
interface (emX on hostA, ng0 on hostB) has an MTU of 1500 (emX) and 1492
(ng0). That should already give enough room (>200byte) for IPSec headers
(as long as the whole path between both hosts does support an MTU of 1500).

I'm currently in the process of switching to FAST_IPSEC on both machines
and will repeat the test. It takes a bit longer as both machines are
remote to me.

Thanks for your help!

Volker

Yvan wrote:
> 
> As I said before, this really looks like problems I regulary see, when
> the ESP packets will have to be fragmented (ESP adds an encapsulation
> level).
> 
> Use a lower MTU on your traffic endpoints or play with the TCPMSS
> value on one gate (at least pf can be configured to do that), and
> ensure that there is no more fragmented ESP packets between the IPSec
> gates (of course, TCPMSS solution is easier to set up, but will only
> work for TCP sessions...).
> 
> ESP maximum overhead is 4 (SPI) + 4 (seq number) + 255 (padding) + 2
> (pad len + next header) + 96 (SHA-1-96 auth value, see RFC 2404)
> bytes, but usually, overhead will be around 100 bytes (including
> authentication, but ESP should really not be used without
> authentication), so setting up for internal hosts an MTU of (Public
> Interface MTU) - 150 should be enough, without really decreasing
> global performances.
> 
> 
> You should also have better performances when this will be fixed.
> 
> 
> 
> Yvan.
> 
> -- NETASQ - Secure Internet Connectivity http://www.netasq.com