Large packets getting lost; changing MTU works *sometimes*
I have a BSNL DataOne Broadband connection in India and I have it working without any problems on my Ubuntu Linux running on AMD64 (the OS is 32-bit). I have no problems whatsoever connecting to any site on the internet. My ADSL modem is a Huawei MT882.
My company allows people to connect to office from home on a Cisco VPN client (Ver. 4.6.00). I downloaded the Linux version of the client from an internal site, compiled, etc, and am able to connect to my office through VPN. So far so good.
However, when I telnet to my office machine, it invariably hangs when I do even an "ls -al". However, "ls" on a directory with one or two files succeeds. When I tried to connect using the Citrix ICA client, all I get is a blank screen (or sometimes a blob of what should be the login prompt), and there's no way I can connect.
I read on the net that this might be a problem with my MTU setting, and increased the MTU to 2000 using "sudo ifconfig eth0 mtu 2000". SOMETIMES THIS WORKS. I get the ICA client (and telnet too) working, and I can connect to office and work as long as I wish (well, sometimes it disconnects after a couple of hours or so - even the modem's ADSL Link LED stops glowing).
The funny thing is - the success because of changing the MTU is NOT AT ALL REPEATABLE. If it works once, it doesn't mean it'll work again either in 10 mintues or tomorrow. I've tried MTU's all the way from 1100 to 2000, and no value seems to make it work always. Another thing I've observed is - it's *harder* to get it working during the day, and easier early in the morning and late in the evenings. Please note that there's always a "probability" that it connects!
Ubuntu comes with ipv6 enabled by default; I disabled that acting on somebody's advice. That changed NOTHING.
Please help. I've knocked on every door known to man before I came here!
Re: Large packets getting lost; changing MTU works *sometimes*
increasing the MTU will more likely increase the problems. MTU problems usually arise from the fact that one side is using DF bits in IP header, hits an interface where fragemntation would be needed. The resulting ICMP message (fragmentation needed but DF bit set) never gets back to the sender because of NAT or firewall. So path MTU discovery does not work.
A MTU of 1300 on your VPN client machine should work well in all cases - from your side! Still the servers in the HQ might run into the same issue, so contact your IT department.
You can try to analyze the TCP session setup with a packet analyzer like etherreal, which could telly you what is going wrong - look for packet sizes and TCP max segment size.
What also could be is that you have an overloaded internet connection and packet loss there is giving this result.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...