Yvan,
>>2) a gif tunnel
>
> No, and that's the main difference for now: I *never* used Gif
> interfaces.
And that's the point. When not using a gif interface to pass traffic
through the IPSec tunnel, I don't see any trouble at all and everything
works fine. As soon as a gif interface is invo
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
On Sat, Oct 22, 2005 at 10:01:46PM +0100, Volker wrote:
[]
> Is anybody else here with deep TCP + IPSec knowledge able to get a look
> into this? Any known issues? Is there anything I might also check out?
> Is there a 64k limit with IPSec? :(
IPSec works, even for huge datas sessions: I'm usi
Matthew Grooms wrote:
Volker,
ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the
> problem. This behavior is 100% reproducible for me. If traffic is
> forwarded from the host providing the ESP protection or if the
Sorry, this should have read ...
> problem. This behavior
Volker,
I have noticed the same problem. In my case, it only seems to
happen when the traffic is being forwarded across interfaces and pf or
ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the
problem. This behavior is 100% reproducible for me. If traffic is
forwarded
Matthew,
thanks for your reply. Glad to hear that I'm not the only one
experiencing this problem. So the problem is IPSec + firewall but not
related to pf or ipfw. Is it IPSec + bandwidth management??
I've tried a different test setup and just pushed a bunch of
(/dev/random) data over a tcp conne
