dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
25
share rss forum feed


Ben J
Triple Play Architect
Premium
join:2011-09-16
Fort Wayne, IN
kudos:9
reply to garrettm

Re: [FiOS] Cannot map drives when on corporate VPN thru Frontier

Wouldn't be on the Actiontec.

Your PC and the server automatically detect the MTU of the network and adjust their packet sizes accordingly. If you filter ICMP unreachables anywhere between you and the server, you'll break PMTUD. This generally means that if any link in the path has an MTU smaller than 1500, the connection won't work very well, because the PC/server will just "assume" it's 1500 (the MTU of their local ethernet interface) and keep trying that size. Any packet that gets transmitted above the MTU gets lost and the PC/server never adjusts.

A VPN makes this worse, because it must encapsulate the packets, thus making the MTU even smaller.

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.

So when I hear "it works on one path but not another path", the first thing I think of is a link in the middle with a smaller MTU, and PMTUD is broken becausse ICMP is filtered.
--
Transparency Disclosure and Disclaimer: I am a Frontier employee posting in my own personal capacity. The opinions and positions expressed are my own and do not necessarily reflect those of Frontier.


Smith6612
Premium,MVM
join:2008-02-01
North Tonawanda, NY
kudos:24
Reviews:
·Verizon Online DSL
·Frontier Communi..

2 edits
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.