MTU & Fragmentation

Unanswered Question

I have formed an ipsec tunnel between cisco pix ver 7.0 and fortigate firewall. both firewall connects internet via DSL link.The applications running behind the pix firewall is above 1500 bytes, the pix physical interface is set to 1500 bytes.tunnel is fine but i cant send packets above 1419 bytes via tunnel,how to fix this issue,experts help pls



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Atri Basu Sat, 08/28/2010 - 06:12
User Badges:
  • Cisco Employee,

Hey Pramod,

Here is a link that describes the fragmentation issue with VPN in detail:

More specifically the following portion of the link addresses how to solve fragmentation issues:

Hope this helps.


Jitendriya Athavale Sat, 08/28/2010 - 06:55
User Badges:
  • Cisco Employee,

could you please tell me what connection are you using, is it T1,PPPOE etc

secondly also let me what transform set you are using

what is the mtu set on both asa and fortigate interfaces

praprama Sat, 08/28/2010 - 23:46
User Badges:
  • Cisco Employee,


Where exactly are you seeing the below error message with regards to the DF bit? The application that you are using, does it send packets with the DF bit set in the IP header? (You can see this if you apply captures on the particular host where the application is running). If the DF bit is set, it tells any device in it's path that fragmentation is not allowed for this packet and that could be the reason why the PIX is dropping these packets as the default MTU is 1500 bytes. You can enable logging on the PIX and check the logs to see if there any logs relating to such issues.

You might want to try the command "crypto ipsec df-bit clear-df ".

Also, as the packets being sent by the application is going to be greater than the MTU on the PIX, you might want to lok at the below command as well:

Let me know how it goes!!



praprama Sun, 08/29/2010 - 07:02
User Badges:
  • Cisco Employee,


The ping that you are running has a size greater than the MTU of the PIX and also the DF bit of those packets is set. That i guess is the reason why the PIX is dropping those packets. Try pinging with the DF bit cleared (on a linux machine, i guess it's going to be "ping -M -s 1418) and let me know how it goes.

Also, please check if the application you are trying to run also has the DF bit set in the packets (by running captures on the host or by gathering logs from the PIX when trying to run the application).

Thanks and Regards,


On my linux box

i tried

#ping -M do -s 1418

icmp_seq=1 Frag needed and DF set (mtu = 1434)

when the below is issued

#ping -M dont -s 1418

no replies


#ping -M want -s 1418

no replies

(((((-M hint
              Select  Path  MTU  Discovery strategy.  hint may be either do (prohibit fragmentation, even local one), want (do PMTU discovery,
              fragment locally when packet size is large), or dont (do not set DF flag)  )))))

what might be the issue,

What i have to do on pix end ?

Atri Basu Sun, 08/29/2010 - 09:04
User Badges:
  • Cisco Employee,

Hey Pramod,

IP supports a maximum length of 65,536 bytes for an IP packet, but most data-link layer protocols support a much smaller length, called a maximum transmission unit (MTU). Based on the supported MTU, it can be necessary to break up (fragment) an IP packet to transmit it across a particular data-link layer media type. The destination then has to reassemble the fragments back into the original, complete IP packet.

When you use a VPN to protect data between two VPN peers, additional overhead is added to the original data, which can require that fragmentation occur. This table list fields that potentially have to be added to the protected data in order to support a VPN connection:


Note that multiple protocols can be necessary, which increases the size of the original packet.

When the source sends a packet to a destination, it places a value in the control flags field of the IP headers that affects fragmentation of the packet by intermediate devices. The control flag is three bits long, but only the first two are used in fragmentation. If the second bit is set to 0, the packet is allowed to be fragmented; if it is set to 1, the packet is not allowed to be fragmented. The second bit is commonly called the don't fragment (DF) bit. The third bit specifies when the fragmentation occurs, whether or not this fragmented packet is the last fragment (set to 0), or if there are more fragments (set to 1) that make up the packet.

One of the four areas that fragmentation may cause a problem is that the source in the IP header of the packet can set the third control bit to don't fragment, which means that, if an intermediate device receives the packet and must fragment it, the intermediate device cannot fragment it. Instead, the intermediate device drops the packet.In you case your packets are already larger than the MTU set for your device, and on top of that IPSEC headers need to be added forcing furher fragmentation.

To solve fragmentation issues please ensure the following changes are made to your PIX:

1. MTU Change on the ASA/PIX:

    On ASA/PIX devices, use the mtu command to adjust the MTU size in global config mode:

          security appliance (config)# mtu Outside 138

2. MSS Change on the ASA/PIX:

    In order to ensure that the maximum TCP segment size does not exceed the value you set and that the maximum is not less than a specified size,     use the sysopt connection command in global config mode.

                    security appliance (config)# sysopt connection tcp-mss MSS_size_in_bytes

3. Clear Don't Fragment (DF) or handling large files or packets.

    IF you get this MTU size-error message in the syslogs:

PMTU-D packet 1440 bytes greater than effective mtu 1434,
 dest_addr=, src_addr=, prot=TCP

    then to resolve this, be sure to clear the DF bit from the outside interface of the device. Configure the DF-bit policy for IPSec packets with thecrypto     ipsec df-bit command in global configuration mode.

pix(config)# crypto ipsec df-bit clear-df outside

The DF bit with IPSec tunnels feature lets you specify whether the security appliance can clear, set, or copy the Don't Fragment (DF) bit from the encapsulated header. The DF bit within the IP header determines whether a device is allowed to fragment a packet. Use the crypto ipsec df-bit command in global configuration mode to configure the security appliance to specify the DF bit in an encapsulated header. When you encapsulate tunnel mode IPSec traffic, use the clear-df setting for the DF bit. This setting lets the device send packets larger than the available MTU size. Also this setting is appropriate if you do not know the available MTU size.



praprama Sun, 08/29/2010 - 21:46
User Badges:
  • Cisco Employee,


So once you clear the DF bit and ping, it looks like the PIX is no longer dropping it. Do you also have the "crypto ipsec df-bit clear-df" command on the PIX? What does the output of "show crypto ipsec sa" look like? Do you see encrypts on the PIX? What is the encryption setting on the PIX currently: "before encryption" or "after encryption"?

Also, all this troubleshooting we are performing is assuming that the application actually sets the DF bit in the IP header? If it is setting the DF bit, then no matter what we do, the PIX will end up dropping the packets. If it does not set the DF bit, then the PIX must be encrypting the packets and sending it over which again can be confirmed using the output of "show crypto ipsec sa".



ASDM setting below

interface              pre-fragmentation                              df bit policy

inside                     YES                                                copy

outside                   YES                                                clear

praprama Mon, 08/30/2010 - 00:55
User Badges:
  • Cisco Employee,

What about the output of "show crypto ipsec sa" when sending pings of size greater than 1418 bytes. Do you see encrypts count increasing? What happens when you run the particular application?



I can see the below output

    Crypto map tag: outside_map, seq num: 8, local addr:

      access-list outside_8_cryptomap permit ip time-range now
      local ident (addr/mask/prot/port): (local lan ip/
      remote ident (addr/mask/prot/port): (remote lan ip/

      #pkts encaps: 20411, #pkts encrypt: 21196, #pkts digest: 21196
      #pkts decaps: 16697, #pkts decrypt: 16697, #pkts verify: 16697
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 20411, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 784, #pre-frag failures: 0, #fragments created: 1568
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: , remote crypto endpt.:

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: B8A94250

in wireshark i can see mainly tcp packets are getting dropped

I have modified the fragmentation parameters from its default, i just want to check whether my config for fragmentation is correct or not ?

inside interface:

crypto ipsec fragmentation before-encryption inside

crypto ipsec df-bit copy-df inside

outside interface:

crypto ipsec fragmentation after-encryption outside

crypto ipsec df-bit clear-df outside

Should i have to modify any of these settings ?


The default settings in ASA for inside and outside interface is below

inside interface:

crypto ipsec fragmentation after-encryption inside

crypto ipsec df-bit copy-df inside

outside interface:

crypto ipsec fragmentation after-encryption outside

crypto ipsec df-bit copy-df outside

One more info i needed is should i have to adjust my tcp mss,

default value is 1380

i adjusted to the below

systemopt connection tcp mss 1400

Let me know if i am wrong

Atri Basu Tue, 08/31/2010 - 00:57
User Badges:
  • Cisco Employee,

Please change the configuration on the inside interface to clear the DF bit instead of copying it and try it.


This Discussion