From time to time when upgrading our ASA5520 firewalls, there is a change in how PMTU-D is handled by the ASA. When the ASAs were first installed it worked with no issue. After a certain upgrade the firewall started sending the ICMP DF bit set packets sourced from it's outside interface for VPN tunnel connected sites. I had to put in a NAT rule that said not to nat from the inside network to the ASA's outside interface IP address to make it work again.
Some time later after an upgrade, the ASA started sourcing the ICMP DF bit set packets from it's inside interface IP address, but it still said outside in the log messages. I had to change the NAT rule to not NAT to the outside but this time with the inside interface IP address.
Our latest upgrade 8.2(2) has broken PMTU-D again, but this time it is showing the same IP and interface in the log messages as the last version, but we are now getting NAT RPF error messages and the packets are dropped. Below are the log messages. I don't understand why the packets are not just sourced using the inside IP address and showing it as an inside interface. Has anyone else had this issue?
This packet was from server 192.168.2.9 on the inside to remote L2L VPN host 10.135.1.5 on the outside. 192.168.1.1 is the ASA inside interface IP address even though it shows as outside in the log messages which is why I had to put in the NAT statement in the previous ASA version.
Jul 19 2010 11:38:13: %ASA-6-602101: PMTU-D packet 1436 bytes greater than effective mtu 1406, dest_addr=10.135.1.5, src_addr=192.168.2.9, prot=UDP
Jul 19 2010 11:38:13: %ASA-7-609001: Built local-host outside:192.168.1.1
Jul 19 2010 11:38:13: %ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:192.168.1.1 dst inside:192.168.2.9 (type 3, code 4) denied due to NAT reverse path failure
This issue was resolved by upgrading to version 8.3(2). I no longer needed the previous work around NAT statements. Before 8.2(2) I was able to work around the issue by either setting up no NAT from the inside network to the outside or the inside interface of the ASA depending on how the particular version sourced the PMTU-D ICMP packets. On 8.2(2) I was no longer able to get that to work. It kept giving a NAT reverse path error that I couldn't figure out now to get around. I hope going forward I won't have to deal with this issue anymore.
The NAT configuration in the ASA changed with 8.3 so you'll probably have to convert your current NAT statements. They didn't convert automatically during the upgrade for us. We also had to install more RAM in our ASAs to support 8.3.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...