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
lesmikes...@gmail.com
