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:126.96.36.199 to inside:188.8.131.52 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?
Cisco Adaptive Security Appliance Software Version 8.0(4)43
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 184.108.40.206 255.255.0.0 220.127.116.11 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.
18.104.22.168 - resides behind GRE tunnel on the access router which is upsteam from the ASA FW.
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:22.214.171.124 to inside:126.96.36.199 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)
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...