This document describes a situation that might be encountered when upgrading an ASA from version 8.1 or 8.2 to version 8.3. In particular, configurations involving VPN connections and "nat 0" statements might encounter this issue. The problem is not a bug, but a side effect of how Network Address Translation (NAT) works in version 8.3.
One of the symptoms of this problem is that some traffic will be dropped by the ASA, and the log
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows
will be generated by the firewall.
Upgrading to version 8.3(2) might add the 'unidirectional' keyword to all policy-nat exemption lines due to the bug referenced below. This problem causes the same symptoms as the issue discussed in the remainder of this document:
This issue most commonly causes a problem with remote VPN subnets attempting to send traffic inbound to the ASA; after the upgrade this traffic might fail. Removing the 'unidirectional' keyword will allow inbound connections from the VPN client to match these manual nat translations, and the connection should work ok (as per the bug release-note). Please continue reading to learn about other potential (non-bug) causes for the Asymmetric NAT rule problem
Consider the above toplogy, showing an ASA with three interfaces; inside, outside, and dmz. The version 8.2 NAT configuration has the following statements that perform nat on the traffic:
access-list nonatinside extended permit ip 10.10.0.0 255.255.0.0 192.168.1.0 255.255.255.0 access-list nonatdmz extended permit ip 10.10.6.0 255.255.255.0 192.168.1.0 255.255.255.0
This policy nat-exemption statement dictates that traffic sourced from the 10.10.0.0/16 network on the inside interface should not be translated when accessing the 192.168.1.0/24 network across the tunnel on the outside interface.
nat (dmz) 0 access-list nonatdmz
Similar to the first statement, this dictates that traffic received on the dmz interface sourced from the 10.10.6.0/24 network destined to the remote 192.168.1.0/24 network should not be translated by the ASA.
nat (inside) 1 0.0.0.0 0.0.0.0 global (outside) 1 interface
These lines provide outbound Port Address Translation for traffic flowing from the inside to the outside interface.
This is a static translation mapping the local address of 10.10.6.20 to the global 184.108.40.206. This allows outside users to connect directly to the ip 220.127.116.11 and connect to the dmz server. When this ASA is upgraded to version 8.3(1), the NAT translation will be migrated to the new NAT configuration style. This new NAT scheme is completely object-oriented and the syntax from the previous NAT configuration is different. More information on the new NAT system can be found here:
However, after the upgrade inbound connections from the remote host at 192.168.1.5 destined to the DMZ server IP 10.10.6.20 will fail; Inbound ping packets received over the tunnel that match this flow will be dropped by the ASA, and the following syslog will be generated:
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows;
In this case, the problem stems from the first entry in the manual NAT table. In version 8.3, extra checks are performed on packets traversing the firewall if they are subjected to address translation. Specifically, the ASA checks to ensure that a local-ip (a real host ip) exists only on one interface, so that there is no possibility of an address translation overlap. When it detects this problem, it logs the syslog 305013. In this case, the problem is caused by the first manual NAT statement. The configuration lines below:
Notice that the host we are trying to ping on the DMZ is 10.10.6.20, yet the first manual NAT statement (which references the object obj-1010.0.0) indicates that the object "obj-10.10.0.0" represents the real ip addresses of hosts behind the inside interface; obj-10.10.0.0 is defined as the 10.10.0.0/16 network, and this subnet overlaps with the subnet that resides behind the DMZ interface. Because of this overlap, the packet fails the NAT check, and the inbound packet is denied by the firewall.
The solution to the problem is to refine the local object in the first manual nat statement, so that the subnet does not overlap with the subnet on the dmz. Here we create a new object called 'inside-network' which is more specific, and does not overlap with the dmz. Then we remove the old manual NAT statement, and replace it with a new one which references the new object we created