08-28-2010 05:15 AM
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
08-28-2010 06:12 AM
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:
Hope this helps.
Regards,
Atri.
08-28-2010 06:55 AM
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
08-28-2010 10:54 PM
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
08-28-2010 11:00 PM
The issue is host behind the pix if it send a packet beyond 1418 to remote host via ipsec tunnel its dropped
ping
i can see DF set (1434) & dropping
08-28-2010 11:46 PM
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
08-29-2010 05:17 AM
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
From
and packet is dropped.
08-29-2010 07:02 AM
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
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
08-29-2010 08:23 AM
Hi,
On my linux box
i tried
#ping -M do
icmp_seq=1 Frag needed and DF set (mtu = 1434)
when the below is issued
#ping -M dont
no replies
similarly
#ping -M want
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 ?
08-29-2010 09:04 AM
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=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.
08-29-2010 09:46 PM
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
08-30-2010 12:31 AM
ASDM setting below
interface pre-fragmentation df bit policy
inside YES copy
outside YES clear
08-30-2010 12:55 AM
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
08-30-2010 02:06 AM
I can see the below output
Crypto map tag: outside_map, seq num: 8, local addr:
access-list outside_8_cryptomap permit ip
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.:
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: B8A94250
in wireshark i can see mainly tcp packets are getting dropped
08-30-2010 09:18 PM
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
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: