[Openswan Users] Problems with Large Packets? - ps ax hangs in ssh - tunnel over wireless network

[Markus Meissner]

Tomasz Grzelak <mailto:tgrzelak at wktpolska.com.pl> wrote:
> Markus Meissner wrote:
>> I have a very odd problem with a new tunnel. In quick words: I have a
>> tunnel for two subnets over a wireless-link. Without the tunnel
>> everything works like a charm, fast and reliable. After setting up the
>> tunnel everything looks ok, I can ping a host from one subnet to
>> another and I can log in via ssh. But if I try to execute commands on
>> the remote host, the console "hangs". The problem is 100% reproduceable
>> with the following commands: 
>>
>> while true; do date; done -> creates much output, runs without
>> problems "ps ax" or "find /" hangs after a few letters. Always.
>> Sometimes after 10 letters, sometimes after 100 letters, but never back
>> again to my shell. 
> 
> it looks exactly like an mtu problem; I had the same
> 
>> Testing this on the console (with tunnel enabled) is ok, no problem.
>> Testing it without tunnel per ssh is ok, no problem. Other services
>> like http or smb behave the same: No problem without tunnel, hangs with
>> tunnel. 
>> 
>> I found a hint in the faq that this might be an MTU problem. I tried
>> to set overridemtu=1430 on both sides but is has no effects.
> 
> I don't know why
> I think we should ask Paul or Jacco if the option works in OpenSwan 2.x.y
> 
>> So, please help me: I don't know where to debug this problem. What can I
>> do? 
>> 
> 
> first read some articles, they may give you some answers and/or more
> light on the case: 
> 
> http://www.netheaven.com/pmtu.html
> http://alive.znep.com/~marcs/mtu/

Thanks for the quick response. I think I have now understood the mtu
problem.


> check if you allow to pass icmp responsible for the MTU discovery; maybe
> you block them, and if you let them through it would solve the problem...
> maybe...  

Checked by disableing the whole firewall, setting all to ACCEPT. No change.


> On the other hand you have another choice that worked for me - add the
> following rules to the iptables script: 
> 
> $IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1416
> 
> (apply it for all packets going through the tunnel) I know it does not
> solve the problem for the upd "big" packets, but for tcp connections it
> really suites my needs.  

It would suite my needs, too, but it doesn't work. I have added the rule on
both gateways and checked that they have catched some packets, but I have
still the same effect. 

Uah, 10 minutes later =) I have set the mtu on the client (the ssh-server)
to 1413 and it works! What I don't understand is that I have to set the mtu
on the "client" and one hop later, on the gateway, it doesn't work. I have
tried to decrease the mtu via ipsec.conf, your iptables-rule above and via
the interface to the subnet, nothing works. Is this a hint for someone whats
going on here? Is there a way to set the mtu for the whole subnet? Or might
this be a problem with the subnet/network-card of the gateway? There are
other clients in the subnet that are still not connected, so I think that it
is not a problem of the client. The switch? Many open questions...

-- 
Beste Grüße / best regards Markus Meissner