Showing results for 
Search instead for 
Did you mean: 


PMTU-D changes in ASA firewall 8.2(2)

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 on the inside to remote L2L VPN host on the outside. 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=, src_addr=, prot=UDP

Jul 19 2010 11:38:13: %ASA-7-609001: Built local-host outside:

Jul 19 2010 11:38:13: %ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside: dst inside: (type 3, code 4) denied due to NAT reverse path failure

Jul 19 2010 11:38:13: %ASA-7-609002: Teardown local-host outside: duration 0:00:00

This is the NAT command that worked before, but not after the upgrade. I removed this NAT rule hoping it would fix the issue, but it didn't.

access-list remote extended permit ip host

nat (inside) 0 access-list remote

Any help is greatly appreciated.





Did you ever find a resolution to this?  We're having a similar, if not exact, problem.





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.


Content for Community-Ad