I have an ASA on the edge of my network. When I traceroute from an outside host to an inside host, the last few hops all appear as the NAT IP for the inside host.
I have turned on ICMP inspection and ICMP error inspection.
I was able to replicate the conditions in VIRL. I have found that the cause of this issue is when I enable port-overloading. We use port overloading for web access, which covers anything that doesn't have a more specific NAT rule applied. We use config something like this:
nat (inside,outside) after-auto source dynamic any Overload-IP
The thing that I can't understand is this; Why does the router between the ASA and the inside host use the NAT IP of the inside host, and not the IP from the port-overload?
Also, is there a way to fix this behaviour? I thought about a NAT exemption rule at the top of the list, but I don't think I can create an exemption for just ICMP traffic.
From here I can see that normally (without icmp error inspection), the ASA will translate the error packet based on the destination IP of the packet that caused the error. It gets this information from the ICMP payload.
Turning on icmp error inspection allows the ASA to rewrite this IP with the real IP of the device that's sending the error. That's why the traceroute looks right after enabling error inspection.
However, config like this:
nat (inside,outside) after-auto source dynamic any Overload
seems to override this behaviour, and prevent the ASA from rewriting the ICMP error with the real IP.
Does anyone know why?
Here is part of the packet tracer result for an ICMP time-exceeded error coming from the inside:
Application Protection, Availability & Security
Join our webinar May 6th to gain valuable industry insights into the most recent application cyber attacks and to understand the potential impact bot traffic is having on your business.
The purpose of this document is to demonstrate how ISE authenticate / authorize a user that uses a smart card (PIN + Certificate) and password mechanism to login their system. This document describes the components used for this setup, configuration of IS...
For all versions of the Email Security Appliance (ESA) and Security Management Appliance (SMA), some Secure Sockets Link (SSL) certificates issued from the QuoVadis root certificate authority (CA) trust chain before 2021-03-31 cannot b...
Automation and programmability for networking and security are increasingly important topics. Every release since ISE 1.2 has included new REST API capabilities to better automate and integrate ISE with the rest of your network, appli...