k h wrote:
>
>
> I'd suspect the VPN first. They normally encapsulate packets,
> reducing the maximum size for the original data which must then be
> fragmented if it was already at the maximum packet size. If the
> sender sets the DF (don't fragment) bit, which is often done
> unnecessarily, it will fail and have to try to determine the largest
> packet size that will go through. And this will fail if
> intermediate firewalls block the required ICMP packats as they
> usually do in situations where VPNs are needed. You could try
> setting the MTU lower on the client to work around the problem.
>
>
> Many thanks. It appears that was the problem. I was inclined to blame
> the horrible Cisco AnyConnect VPN myself, but i) icmp echo-requests get
> through fine, and ii) ssh/www/samba work apparently correctly over it.
> (It would still be horrible even if it turns out to be some firewall's
> fault :-) )
>
> For others, the command to try under Linux is something like sudo
> ifconfig eth0 mtu 300, You should probably use a higher value than 300
> once it works (1200?).
>
> Once again, many thanks for your help.
The ethernet max is 1500 and VPN encapsulation might by 40 bytes, so 1460 is
probably good. If the vpn endpoint is software on the same machine, I'd expect
the correct value to be picked up from the interface itself. If it is
elsewhere, the firewalling must permit the ICMP 'fragmentation needed' message
from the 'outside' interface of the router that can't pass it on (and you are
testing only echo-request/reply messages, probably with the tunnel interface).
But, there is still the question of why a subversion client sets the DF bit on
traffic that wouldn't be hurt by IP fragmentation/reassembly in the first place.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-05-09 21:59:44 CEST