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
I am using FAST_IPSEC on a multi subnet VPN with the guys on other side
having Check Point VPN / Firewall.
Its a VPN that does almost non stop usage, the people on the other side
have 24 monitoring utils on it and its never had a problem.
Its on 5.3 i386, and I fear to upgrade it, when it comes t
Max & Co:
I've just seen I'm using kernel config 'options IPSEC' on both machines.
Should I try 'options FAST_IPSEC'? Would take some hours for kernel
recompile. Does the code IPSEC / FAST_IPSEC make a difference (even
while having not hardware crypto accelerator)?
May I use FAST_IPSEC even witho
Max,
I set sack.enable=0 on both FreeBSD machines but the same happens.
Volker
On 2005-10-23 00:40, Max Laier wrote:
> To try something else: Could you guys try to disable SACK on the machines
> involved? I haven't looked at the dumps as of yet, but that's one simple
> test that might help t
To try something else: Could you guys try to disable SACK on the machines
involved? I haven't looked at the dumps as of yet, but that's one simple
test that might help to identify the problem.
sysctl net.inet.tcp.sack.enable=0
On Sunday 23 October 2005 02:23, Volker wrote:
> Michael,
>
> I not
Michael,
I not that sure if I'm right in checking what you suggested but when
trying to do ping hostB from hostA with oversized packets through the
IPSec tunnel by:
# ping -c 10 -s 12000 10.128.6.1
I'm getting replies easily.
While doing that and tcpdump'ing the gif interface, I'm seeing the
fr
Mike & Volker,
>Try sending different sized pings or other packet size control utils to
>really make sure its not MTU related.
>Maybe there is an upstream router thats blocking ICMP fragment packets,
>have you ever seen them? try forcing the creation of some.
>
>Mike
I am experiencing the sa
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
Try sending different sized pings or other packet size control utils to
really make sure its not MTU related.
Maybe there is an upstream router thats blocking ICMP fragment packets,
have you ever seen them? try forcing the creation of some.
Mike
Volker wrote:
Still having the same problem wi
Still having the same problem with an IPSec tunnel between FreeBSD 5.4R
hosts.
Problem description:
scp session tries to transfer a large file through an IPSec tunnel. The
file is being transmitted but scp says 'stalled' after 56K (49152 bytes
file size). The IPSec tunnel itself is still up even a
14 matches
Mail list logo
