LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: December 22nd, 2014
Linux Advisory Watch: December 19th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
( MTU ) - IP MASQ seems to be working fine but some sites don't work. This usually happens with WWW and some FTP sites.

7.15. ( MTU ) - IP MASQ seems to be working fine but some sites don't work. This usually happens with WWW and some FTP sites.

Depending on what Linux kernel version you are running on the MASQ server, some will people disagree on the real problem. The two following arguments have valid points, are inter-related, and users from each camp continue to debate this to this day.

  • With modern 2.4.x Linux systems, most users point their finger at the adminstrators of these remote broken sites (typically SSL-encrypted WWW sites, etc.) or your MASQ server's upstream router run by your ISP. The main though it that these machines are either filtering or not properly responding to SOME or ALL FORMS of ICMP packets (specifically ICMP Code 3 Type 4 - Fragmentation Needed) messages due to a fray of misplaced security paranoia.

    What does that all mean? Basically, say your machine is connected to the Internet with a MTU of 1492 bytes (Maximum Transmission Unit -- the maximum packet size your computer can transmit) which is common for PPPoE users. At the same time, the remote WWW/FTP site is connected to the Internet at a MTU of 1500 bytes. The way that TCP/IP works is that when a TCP connection is being negotiated for your HTTP / FTP connection, the remote side will try to verify that a 1500 byte packet can reach your computer via the initial TCP "SYN" packet.

    Since the packet is too big for your connection, your upstream router (run by your ISP) will send a ICMP 3:4 (fragmentation needed) packet back to the remote WWW / FTP server. Within this packet is a recommended smaller MTU size to retry with. The problem is that either your local upstream router, some router between you and the remote server, or the remote HTTP / FTP server is either misconfigured or has a firewall in front of it that is BLOCKing these ICMP packets.

  • The final UNCOMMON possibility is a debatable 2.0 / 2.2 kernel bug in the IPMASQ code. Some users point their finger to the fact that IPMASQ might have problems with ICMP packets that have the DF or "Don't Fragment" bit set. Basically, when a MASQ box connects to the Internet with an MTU of anything less than 1500, some packets will have the DF field set. Though changing the MTU of the MASQ server's Internet link to 1500 seemingly fixes the problem, the possible bug is still there. What is believed to be happening in these older kernels is that the MASQ code is not properly re-writing the return IP addresses of the ICMP 3 Sub 4 code packets back to the originating MASQed computer. Because of this, these critical packets get dropped.

No worries though. A there are several perfectly good ways to fix this nasty MTU problem:

  • Enable PMTU clamping in PPPoE

    This solution is mostly for modern 2.4.x and 2.2.x kernel users connected to the Internet via a PPPoE DSL or Cablemodem connections. This solution allows for changes to be done ONLY on the MASQ server itself and not on all of the internal MASQ clients.

  • Enable PMTU clamping via IPTABLES

    This solution is only modern 2.4.x kernel users connected via ANY type of Internet connection. This solution allows for changes to be done ONLY on the MASQ server itself and not on all of the internal MASQ clients.

  • Change your MASQ server's Internet Link MTU

    This solution will work for any Linux kernel version but is is NOT a solution if you have a PPPoE connection for DSL or Cablemodem users.

    It should be noted that some users will balk at this solution because it can hurt some latency specific programs like TELNET and Internet games but the impact is only slight. On the other hand, most HTTP and FTP traffic will SPEED UP!

  • Change the MTU of all internal MASQed machines

    This solution requires the most work as you have to make minor changes to ALL of the internal IPMASQed machines. Basically, you would be changing the MTU on all of the internal machines to match the MTU of your MASQ server's Internet connection. Fortunately, this solution is usually bulletproof where as some of the other solutions mentioned in this section might rarely not work.

7.15.1. Enabling PMTU Clamping for PPPoE and some PPP Users:

For those users who use PPPoE clients for (DSL / Cablemodem) or PPP (Dialup), your Internet connection is NOT "eth0" (for example) but usually "ppp0". In addition to this, your Internet link's MTU or Maximum Transmission Unit (largest packet you can transmit over the Internet) isn't 1500 bytes but 1492. The 1492 byte MTU comes from the link size of Ethernet (1518 bytes) - Ethernet MAC overhead (18) = 1500. Then you subtract the PPPoE header (8 bytes) == MTU of 1492. This overhead isn't a big deal but sometimes ISPs or remote Internet sites do stupid things to break PPPoE or non-1500 byte MTU connected machines.

You can find more info about this topic on the web. Specifically, here is good presentaion on the topic: mss-talk presentation (PDF). Here is the entire Write up and other good info

To enable clamping in both the RP or PPPd PPPoE clients, add the following line to your /etc/ppp/pppoe.conf file:


  # - If you have a computer acting as a gateway for a LAN, choose "1412".
  #   The setting of 1412 is safe for either setup, but uses slightly more
  #   CPU power.
  #
  CLAMPMSS=1412
  

7.15.2. Clamping the MSS via IPTABLES:

As mentioned above for PPPoE users, some ISPs and WWW sites filter critical ICMP packets like MTU Path Discovery. Because of this, many users might find more Internet sites work but others hang or work poorly. Fortunately, recent IPTABLES have added PMTU Clamping support which should help you. If your using IPTABLES and think you're hitting this issue, try adding the following line to the end of your rc.firewall-iptables ruleset. It should be noted that there is no PMTU clamping support in IPCHAINS.


 iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
 

If this line causes an error when you re-run the rc.firewall-iptables* firewall rulesets, you might need to upgrade your version of IPTABLES which includes the "TCPMSS" IPTABLES module.

7.15.3. Changing the External MTU of the MASQ server:

This solution usually only applies to DIALUP users since PPPoE users cannot INCREASE their MTU because of PPPoE's header overhead.

To use this solution, first see what your current MTU for your Internet link is. To do so, run "/bin/ifconfig" on the MASQ server. Look at the lines that corresponds to your Internet connection and look for the MTU (for example, ppp0). This NEEDs to be set to 1500. Usually, Ethernet links will default to 1500 for Ethernet but serial / DIALUP modem PPP links might default to 576.

  • To change the MTU on a standard Ethernet link to your bridged or routed DSL, Cablemodem, etc. connection, you need to edit the correct network startup scripts for your Linux distribution. Please see the TrinityOS - Section 16 document for network optimizations.

  • To change the MTU issue on a PPP (not PPPoE) Internet link, edit your "/etc/ppp/options" file and towards the top, add the following text on two seperate lines, add:

    
   mtu 1500
       mru 1500
       

    Save these new changes and then restart PPP. Like shown above, verify that your PPP link has the correct MTU and MTU.

    CUA Users: Lastly, though this isn't a common problem, some Linux 2.0.x kernel users have found a MTU solution to the following problem. With PPP users, verify what port is your PPPd code connecting to. Is it a /dev/cua* port or a /dev/ttyS* port? It NEEDS to be a /dev/ttyS* port as the /dev/cua* device ststem has been deprecated and it breaks some things in very odd ways.

7.15.4. Changing the MTU of various operating systems:

If you reconfigure ALL of your MASQed PCs to use the SAME MTU as your external Internet link's MTU (for example, 1492 for PPPoE users), everything should work fine and this method is sometimes the MOST EFFECTIVE way of fixing things. This is including ALL of the solutions mentioned above. But doing things this way can be a lot of work if there are lots of internal MASQed machines or be even impossible to do if you don't have administrative access to all the internal MASQed machines.

Follow these simple steps for your respective operating system:

The follow examples utilize an MTU of 1492 for typical PPPoE connections for some DSL and Cablemodem users. It is recommended to use the HIGHEST values possible for all connections that are 128Kb/s and faster. It should be noted that some PPPoE ISPs might require an MTU setting of 1460 (not 1492) for proper connectivity due to additional overhead in the ISP's internal network.

The only real reason to use smaller MTUs than 1492 or 1460 is to lower your Internet link's latency but at the cost of throughput. Please see http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu for more details on this topic.

If you know how to make similar changes like these to other OSes like OS/2, MacOS, etc. please email David Ranch so it can be included in the HOWTO.

7.15.4.1. Changing the MTU on Linux:

------------------------------------------
1. The setting of MTU can vary from Linux distribution to distribution.  

   For Redhat: You need to edit the various "ifconfig" statements in 
               the /sbin/ifup script

   For Slackware: You need to edit the various "ifconfig" statements in 
                  the /etc/rc.d/rc1.inet

2. Here is one good, any-distribution-will-work example, edit the 
   /etc/rc.d/rc.local file and put the following at the END of the file: 

        echo "Changing the MTU of ETH0"
        /sbin/ifconfig eth0 mtu 1492

     Replace "eth0" with the interface name that is the machine's upstream 
     connection which is connected to the Internet.

3. For advanced options like "TCP Receive Windows" and such, detailed examples
   on how to edit the respective networking scripts for your specific Linux
   distro, etc., please see Chapter 16 of 
   http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos 
------------------------------------------

7.15.4.2. Changing the MTU on MS Windows 2000

------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
   with a backup copy, you should be safe.  Proceed at your 
   OWN RISK.

2. Goto Start-->Run-->RegEdit

3. Registry-->Export Registry File-->Save a copy of your registry
   to a reliable place

4. Navigate down to the key:

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\<ID for Adapter>

   Each ID Adapter has default keys for DNS, TCP/IP address, Default Gateway, 
   subnet mask, etc. Find the key one that is for your network card.

5. Create the following Entry:

      type=DWORD
      name="MTU"				(Do NOT include the quotes)
      value=1492 (Decimal)      (Do NOT include the text "(Decimal)")

http://support.microsoft.com/support/kb/articles/Q120/6/42.asp?LN=EN-US&SD=gn&FR=0


 *** If you know how to also change the MSS, TCP Window Size, and the
 *** TTL parameters in NT 2000, please email dranch@trinnet.net as I 
 *** would love to add it to the HOWTO.

5. Reboot to let the changes take effect.
------------------------------------------

7.15.4.3. Changing the MTU on MS Windows NT 4.x

------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
   with a backup copy, you should be safe.  Proceed at your 
   OWN RISK.

2. Goto Start-->Run-->RegEdit

3. Registry-->Export Registry File-->Save a copy of your registry
   to a reliable place

4. Create the following keys in the Registry trees, choose two
   possible Registry trees.  Multiple entries are for various 
   network devices like DialUp Networking (ppp), Ethernet NICs, 
   PPTP VPNs, etc.

   http://support.microsoft.com/support/kb/articles/Q102/9/73.asp?LN=EN-US&SD=gn&FR=0


   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip]
                     and
   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Adapter-name>\Parameters\Tcpip]

      Replace "<Adapter-Name>" with the respective name of your uplink LAN NIC 
      interface

         type=DWORD
         name="MTU"              (Do NOT include the quotes)
         value=1492 (Decimal)    (Do NOT include the text "(Decimal>")

       (Do NOT include the quotes)


 *** If you know how to also change the MSS, TCP Window Size, and the
 *** TTL parameters in NT 4.x, please email dranch@trinnet.net as I 
 *** would love to add it to the HOWTO.

5. Reboot to make the changes take effect.
------------------------------------------

7.15.4.4. Changing the MTU on MS Windows 98:

------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
   with a backup copy, you should be safe.  Proceed at your OWN RISK.

2. Goto Start-->Run-->RegEdit

3. You should make a backup copy of your Registry before doing anything.  To
   do this, copy the "user.dat" and "system.dat" files from the \WINDOWS 
   directory and put them into a safe place.  It should be noted that the
   previously mentioned method of using "Regedit: Registry-->Export Registry 
   File-->Save a copy of your registry" would only perform Registry MERGES 
   and NOT do a replacement.

4. Search though each of the Registry trees that end in "n" (e.g. 0007) 
   and have a Registry entry called "IPAddress" which has the IP address
   of your NIC.  Under that key, add the following:

   From http://support.microsoft.com/support/kb/articles/q158/4/74.asp

     [Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
         type=STRING
         name="MaxMTU"            (Do NOT include the quotes)
         value=1492 (Decimal)     (Do NOT include the text "(Decimal)")


5. You can also change the "TCP Receive Window" which sometimes
   increases network performance SUBSTANTIALLY.  If you notice your
   throughput has DECREASED, put these items BACK to their original 
   settings and reboot.

     [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]

        type=STRING
        name="DefaultRcvWindow"    (Do NOT include the quotes)
        value=32768 (Decimal)      (Do NOT include the text "(Decimal>")

        type=STRING
        name="DefaultTTL"          (Do NOT include the quotes)
        value=128 (Decimal)        (Do NOT include the text "(Decimal>")


6. Reboot to let the changes take effect.
------------------------------------------

7.15.4.5. Changing the MTU on MS Windows 95:

------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
   with a backup copy, you should be safe.  Proceed at your OWN RISK.

2. Goto Start-->Run-->RegEdit

3. You should make a backup copy of your Registry before continuing.  To
   do this, copy the "user.dat" and "system.dat" files from the \WINDOWS 
   directory and put them into a safe place.  It should be noted that the
   previously mentioned method of using "Regedit: Registry-->Export Registry 
   File-->Save a copy of your registry" would only do Registry MERGES and NOT 
   do a replacement.

4. Search through each of the Registry trees that end in "n" (e.g. 0007) 
   and have a Registry entry called "IPAddress", which has the IP address
   of your NIC.  Under that key, add the following:

   From http://support.microsoft.com/support/kb/articles/q158/4/74.asp

     [Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]

         type=DWORD
         name="MaxMTU"           (Do NOT include the quotes)
         value=1492 (Decimal)    (Do NOT include the text "(Decimal)")

         type=DWORD
         name="MaxMSS"           (Do NOT include the quotes)
         value=1450 (Decimal)    (Do NOT include the text "(Decimal>")


5. You can also change the "TCP Receive Window" which sometimes
   increases network performance SUBSTANTIALLY.  If you notice your
   throughput has DECREASED, put these items BACK to their original 
   settings and reboot.

     [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
        type=DWORD
        name="DefaultRcvWindow"   (Do NOT include the quotes)
        value=32768 (Decimal)     (Do NOT include the text "(Decimal>")

        type=DWORD
        name="DefaultTTL"         (Do NOT include the quotes)
        value=128 (Decimal)       (Do NOT include the text "(Decimal>")


6. Reboot to let the changes take effect.
------------------------------------------

    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Weekend Edition
Report: U.S. planning “proportional response” to Sony hack, blamed on North Korea
Heartbleed, Shellshock, Tor and more: The 13 biggest security stories of 2014
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.