VPN via ADSL: connection hangs

[Steph]

Archived from groups: comp.dcom.vpn (More info?)

I'm clueless.

I'm trying to connect via VPN to our corporate network using an ADSL
connection. My system is Win XP Servicepack 2, and the VPN connection
is L2TP-IpSec, I use a SpeedTouch 510 modem.

I can successfully connect and open an ssh-connection (using cygwin) to
one of the local servers - but after a short time the connection hangs,
e.g. I issue an 'ls' (unix-style) and some lines are returned and than
it stops dead. But the VPN connection still lives and I can open up
another ssh session - which will die the same way soon after.

As far as I know the MTU size is set correctly by the firewall. I was
told that it's not necessary to change settings on my local machine.
The VPN setup works for other people - but I'm the only one using ADSL.
I'm far from an expert with VPN and I would appreciate any hints to get
this running.

Thanks in advance,
Stephan

 

[Steph]

Archived from groups: comp.dcom.vpn (More info?)

No, it does'nt seem to be connected to inactivity: I connect via ssh,
enter 2 or 3 commands, then it hangs. And there's no difference if i
do it all at once, or if I wait in between. But what is interesting: it
seems that it always hangs when the output is some larger list. For
instance, when i enter 'ls' in a small directory it's no problem, doing
this on a larger one (for instance /usr/lib) it hangs.

 

[Steph]

Archived from groups: comp.dcom.vpn (More info?)

I have to display my lack of knowledge here: Is this max frame size
something that's determined by the firewall, or is this a setting I can
enter on my client machine? (i.e reducing ist would solve the problem)

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

> I can successfully connect and open an ssh-connection (using cygwin) to
> one of the local servers - but after a short time the connection hangs,
> e.g. I issue an 'ls' (unix-style) and some lines are returned and than
> it stops dead. But the VPN connection still lives and I can open up
> another ssh session - which will die the same way soon after.

Maybe related to a firewall dynamic rule state expiration. Are you
transfering information on a continuous basis over the SSH connection ?
If you loose session after a inactivity time, have a look to your
firewall (remote site probably).

Cheers, Alex.
--
www.nucleonet.com

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

It can be seen as user configurable "MTU" (Maximum Transfer Unit)

On 10 Apr 2005 11:07:29 -0700, "steph" <stephan0h@gmx.net> wrote:

>I have to display my lack of knowledge here: Is this max frame size
>something that's determined by the firewall, or is this a setting I can
>enter on my client machine? (i.e reducing ist would solve the problem)

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

steph a écrit :
> No, it does'nt seem to be connected to inactivity: I connect via ssh,
> enter 2 or 3 commands, then it hangs. And there's no difference if i
> do it all at once, or if I wait in between. But what is interesting: it
> seems that it always hangs when the output is some larger list. For
> instance, when i enter 'ls' in a small directory it's no problem, doing
> this on a larger one (for instance /usr/lib) it hangs.

I have already seen this on firewall and max frame size negociation in
TCP. For example, if your TCP session negociates 1500 bytes as max frame
size but something in the middle is performing fragmentation (tunneling
over UDP, IPsec) then the remote firewall can suppress additionnal
fragment (ie linux ipfilter/iptables).

You can try to discriminate this behavior with a packet sniffer to see
if fragments are built and dropped by an equipment on the path.

Hope this helps.

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

Am 9 Apr 2005 13:36:15 -0700 schrieb steph:
I'm running into the same prob.

MTU is down to 1300 (!!) but the freeze of output still is the same. Seems
to depend of the output. For example ls in large directories works well but
ls -a hangs.
Even top hangs.

;-(

Regards,
Matthias