said by Ben J:
This actually happens a lot when uninformed people (your typical IT engineers) finish reading their Security+ book and scream "RAWR!! ICMP BAD!!!" and filter it, without understanding the broader implications of doing so. IT engineers have gotten lazy because ISPs have worked hard over the past 15 years to ensure all links support at least 1500. But there is no guarantee it's always the case.
I have to agree with this and see it constantly. It seems to be more common with the governmental-related institutions around here as well. ICMP is so filtered out to the point where MTU Path Discovery absolutely fails to operate. Often times it's restrictive enough to the point where you can't traceroute anything beyond the initial router you have to go through even though there's still a router or two left on the Intranet, which does not need ICMP filtering. The WAN is often filtered to the point where you can't ping or traceroute beyond the firewall from either direction but Path discovery still works fine. Those are often networks I find that run terrible (as in, sites that won't load, VPNs that bug out completely, etc) even when they have a Gigabit+ connection coming in with an unspecific MTU. Host to Host communication within the Intranet is often what doesn't fail to work though. I never bother their IT Dept. about such issues as they generally won't listen anyways, but just some food for thought. It's a matter of taking that nice expensive Firewall you have and making it do what it's supposed to.
A common MTU for VPNs that tends to work well is 1300 bytes per packet. If you temporarily set your host to 1300, see if your VPN starts to work properly, too. VPN traffic does not like being fragmented. Cisco AnyConnect can be set up to use a number of different procotols, the default being SSL-based encryption which each has further amounts of overhead based on what they are. The older, no-longer-supported Cisco VPN Client often came with a "Set MTU" tool that defaulted all of the host's interfaces to 1300 to compensate for the overhead from IPSEC-based VPN and to also make room for lesser connections like PPPoE-based DSL.