11-11-2015 01:59 PM - edited 03-11-2019 11:52 PM
I have two ASA 5510s connected over a WAN, running IPsec (AES-256). I'm not getting any errors, but the application is getting clobbered. The application is using Linux IPsec. Where do I start looking, in regards to packet capture, MTU problems, MSS issues, etc?
Thanks.
Solved! Go to Solution.
11-13-2015 10:53 AM
Fragmentation is a CPU intensive process as you have to segregate the packets by looking at the MTU size and then other side has to reassemble them so that it can be presented properly to next layer.
Why ASA doesn't allow fragementation by default?
If the ASA started entertaining all the packets and fragmenting them , it would cause high utilization of resources and it will render the ASA unusable for other relevant functions which are basic operational features of the firewall.
Thus the default behvior is to copy the df-bit so that if it is cleared , it is reflected and likewise for df-bit set scenario.
Here is a good read that might give you more insight:
http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
11-11-2015 03:10 PM
What we found resolved this was to change the df-bit from copy to clear (crypto ipsec df-bit clear-df ), and MTUs to 1380.
Any other insight on how this worked would be appreciated
11-12-2015 12:58 AM
Just to add on to previous suggestion, it is always recommended to tweak MSS rather than MTU so that we are able to change the segment size to allow the communication and not restrict the packet size by lowering its MTU.
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
11-13-2015 07:48 AM
Thanks Dinesh,
Can you explain why changing the ipsec df-bit to clear-df fixed my problem? what does that do instead of copy-df?
11-13-2015 10:17 AM
Hi Jimmy,
Thanks for rating. The reason why it resolved the issue because in various scenarios, if we have the df bit set from the client and the MTU size is more than what can be accomodated, in such cases , the packet is dropped. Thus we clear the df bit so that the necessary fragmentation can be done for such packets.
If you copy df-bit, then if it is set , it will be reflected in the outbound packet as well and it might get dropped cause the ASA wont be able to fragment it as the MTU size might exceed the threshold due to overhead from encryption.
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
11-13-2015 10:41 AM
Many thanks Dinesh; you are most helpful. What I can't understand is why the ASA doesn't allow fragmentation by default? Is that because of security, where malware is introduced in fragemented packets?
11-13-2015 10:53 AM
Fragmentation is a CPU intensive process as you have to segregate the packets by looking at the MTU size and then other side has to reassemble them so that it can be presented properly to next layer.
Why ASA doesn't allow fragementation by default?
If the ASA started entertaining all the packets and fragmenting them , it would cause high utilization of resources and it will render the ASA unusable for other relevant functions which are basic operational features of the firewall.
Thus the default behvior is to copy the df-bit so that if it is cleared , it is reflected and likewise for df-bit set scenario.
Here is a good read that might give you more insight:
http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
11-11-2015 08:50 PM
Hello Jimmy,
I will suggest you to start off with this document that helps in understanding how to discover and mitigate fragemtation issues.
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/82444-fragmentation.html
In a nutshell, you will need to test by sending unfragmented packtes with larger payload and decreasing them step by step to find the correct MSS where the fragmentation is not happening.
Just follow the section "Troubleshoot: VPN Encryption Error" in the above said document and it should address your query.
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
11-13-2015 12:17 PM
Tunnel0 Interface status: protocol-down, link-down, admin-up
How do you resolve a CGR with the following info; "Tunnel0 is down (Internal-Handshake-Fail errDisable)
and Tunnel1 is down (No route to tunnel destination address)?" respectively....Thanks in anticipation
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: