XLATE NAT from inside to inside issue

[seltser_michael]

Hi All:

We experienced an outage which was later discovered as a result of xlate table entry containing a dynamic NAT for a given IP.

I've perform additional research and found that NAT table contains additional 3-4 other entries with similar cases as I've provided below.  In my samples, both hosts belong to a remote site which are reachable via an IPSEC tunnel.

NAT from inside:10.5.22.45 to inside:10.5.22.45 flags iI

NAT from inside:172.11.10.167 to inside:172.11.10.167 flags iI

Upoin issuing "clear xlate global 10.5.22.45", the problem get's resolved  immidiately but the root-cause hasn't been determined yet.

On the FW, I'm enforcing NAT control therefore the NAT-0 ACLs include entries to prevent the FW from translating the traffic.

I also have ACLs built for the above IPs as part of the crypto-map.

I am hoping someone could shed some light on what could be causing the FW to built a dynamic NAT rules?

Could it be a configuration or routing issue on the FW?

FW version:

Cisco Adaptive Security Appliance Software Version 8.0(4)43

Thanks!

Mike

[Federico Coto Fajardo]

Hi Mike,

Both 10.5.22.45 and 172.11.10.167 belongs to a remote site that is reachable via an IPsec tunnel?

If there's a NAT 0 access-list for this traffic, there should not be a translation (XLATE) for these hosts (for traffic flowing through the tunnel).

One possibility is that, the hosts are reaching the ASA through the tunnel, and they are doing U-turn?

Do you provide Internet access for these hosts through the ASA?

Depending on your statement for the NAT 0 ACL and the Crypto ACL for interesting traffic, the host might be trying to establish a legitimate connection (that leads to a translation on the ASA).

Could you share the ACLs for NAT and VPN?

Federico.

[seltser_michael]

Federico,

As you've mentioned, both IPs belong to the remote-end and are reachable via IPSEC or GRE tunnels.

There is an existing ALCs built for traffic heading out via IPSEC tunnel which should be excluded from the NAT.  Therefore, the "inside_nat0_outbound" ALC is populated with subnet which these hosts belong to:

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.255.255.0 10.5.22.0 255.255.255.0 (hitcnt=0)

access-list inside_nat0_outbound extended permit ip 172.14.0.0 255.255.0.0 172.11.10.0 255.255.255.0 (hitcnt=0)

For some reason, all of the (hitcounts) are showing up as null but  that's a different issue all together.

access-list crypto-vpn extended permit ip 10.0.0.0 255.255.255.0  10.5.22.0 255.255.255.0 (hitcnt=18)

We don't provide Internet access for these hosts.  These are stricly services between sites.

I also don't have any static NATs created for the interesting traffic.

P.S.  Here are a couple of additional details about hosts in question here:

10.5.22.45 - resides behind IPSEC tunnel which originates on the same ASA FW.  ASA doesn't have any static routes for this host/network.

172.11.10.167 - resides behind GRE tunnel on the access router which is upsteam from the ASA FW.

Thanks,

Mike

[Federico Coto Fajardo]

Mike,

The ACL applied to the NAT0 is exactly to bypass NAT.
I'm not sure about seeing these messages:
NAT from inside:10.5.22.45 to inside:10.5.22.45 flags iI
NAT from inside:172.11.10.167 to inside:172.11.10.167 flags iI
but, there's no translation happening (the IPs are conserving their real IPs).

The question that I have is the following:
What kind of problem was caused by a remote host being NATed to itself on the ASA?

(This is the expected behavior according to the NAT0 rule anyway)

Federico.