cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
14908
Views
0
Helpful
15
Replies

MTU & Fragmentation

pramod
Level 1
Level 1

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

Regards,

CDSPL

15 Replies 15

Atri Basu
Cisco Employee
Cisco Employee

Hey Pramod,

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

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008081e621.shtml

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

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008081e621.shtml#task2

Hope this helps.

Regards,
Atri.

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

Yes,

the connection type i am using is DSL. (static ip - 1mbps)

both cisco and fortigate mtu is 1500 (both inside as well as outside)

transform set is esp-3des esp-md5-hmac

The issue is host behind the pix if it send a packet beyond 1418 to remote host via ipsec tunnel its dropped

ping -s 1419

i can see DF set (1434) & dropping

Hi,

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:

http://www.cisco.com/en/US/docs/security/asa/asa70/command/reference/c.html#wp1973651

Let me know how it goes!!

Regards,

Prapanch

I tried but not working, but with  default setting in pix (both inside & outside ip as "DF-copy" and fragmentation enabled) if i ping the remote ip

ping -s 1418

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

and packet is dropped.

Hi,

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,
Prapanch

Hi,

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

similarly

#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 ?

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:

fragmentation-2.gif

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=10.70.25.1, src_addr=10.10.97.55, 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.

Regards,

Atri.

Hi,

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".

Regards,

Prapanch

ASDM setting below

interface              pre-fragmentation                              df bit policy

inside                     YES                                                copy

outside                   YES                                                clear

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?

Regards,

Prapanch

I can see the below output

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

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

      #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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: