The inspect icmp error enables the ASA to look into the ICMP payload. The NAT rules looks the l3 header alone and translate it.
With regards Kings On Tue, Feb 14, 2012 at 9:33 PM, Joe Astorino <[email protected]>wrote: > Well I must say, I have labbed this up and I am utterly confused : ) You > are absolutely correct, I am just not clear on how this works. > Specifically: > > - When the inspect icmp error feature is DISABLED, what happens is the > ICMP error coming back to R2 is sourced from R1's Fa0/0 interface IP > despite the fact that there is a static NAT for it. How is this possible? > Why doesn't the static nat come into play by default and translate R1 Fa0/0 > IP to the global IP for the ICMP destination unreachable message? > > > On Tue, Feb 14, 2012 at 4:06 AM, Kingsley Charles < > [email protected]> wrote: > >> Joe >> >> The R1's L0's address is not translated, only the R1's F0/0's IP address >> connected to the ASA is translated statically. >> >> When we trace the loopback's real inside address, the ICMP port >> unreachable IP address will have the R1's F0/0's inside IP address and will >> be visible to the outside users. >> >> Enabling icmp inspection will doctor and translate R1 L0's inside IP >> address to public address. >> >> With regards >> Kings >> >> >> On Tue, Feb 14, 2012 at 10:59 AM, Joe Astorino <[email protected] >> > wrote: >> >>> Thanks Kingsley, >>> >>> I want to make sure I understand you 100%. In the situation like the >>> one you posted -- Let's assume R1 has Lo0 and also that it connects to the >>> ASA via Fa0/0. R1 Lo0 is being translated on the ASA to some global address >>> visible to R2. My understanding is as follows >>> >>> - With icmp error inspection DISABLED, when you do the trace to R1 Lo0's >>> global address, both hops would just show up as the global addreess of R1 >>> Lo0 thus hiding the real IP address of R1 Lo0 and R1 Fa0/0 >>> - With icmp error inspection ENABLED, when you do the trace to R1 Lo0's >>> global address, the real IP address of the first hop R1 Fa0/0 shows up in >>> the traceroute. >>> >>> Am I missing something? >>> >>> >>> >>> >>> On Mon, Feb 13, 2012 at 10:03 PM, Kingsley Charles < >>> [email protected]> wrote: >>> >>>> Great work. >>>> >>>> But, the most asked task for "inspect icmp error" is to hide the >>>> original IP address of the router's IP address when tracing it's loopback >>>> interface which is behind the ASA and that ASA is doing translation. >>>> >>>> >>>> R1 (L0) ------------------ASA --------------- R2 (traceroute from here) >>>> >>>> >>>> But this is contrary right :-) >>>> >>>> >>>> With regards >>>> Kings >>>> >>>> On Tue, Feb 14, 2012 at 3:27 AM, Joe Astorino < >>>> [email protected]> wrote: >>>> >>>>> If anybody is interested, I posted a blog on this setup today at >>>>> http://astorinonetworks.com/2012/02/13/asa-icmp-error-inspection/ >>>>> If you have anything to correct or add, I would appreciate it! >>>>> >>>>> >>>>> On Mon, Feb 13, 2012 at 1:12 PM, Joe Astorino < >>>>> [email protected]> wrote: >>>>> >>>>>> I have been doing some extensive testing on this feature so that I >>>>>> better understand it. My findings do not really match up with some of >>>>>> the >>>>>> confusing documentation in the command reference, so I thought I would >>>>>> get >>>>>> some feedback. Either I am misunderstanding something, or the >>>>>> documentation does not add up. >>>>>> >>>>>> My test bed: >>>>>> >>>>>> R1-----ASA1-----R2-----R3-----ACS >>>>>> >>>>>> R1/ASA1: 100.100.100.0/24 <--- ASA "outside" >>>>>> ASA1/R2: 10.10.10.0/24 <--- ASA "inside" >>>>>> R2/R3: 10.10.23.0/24 >>>>>> R3/ACS: 10.10.3.0/24 >>>>>> >>>>>> ASA has a static NAT so the ACS server at 10.10.3.100 is seen on the >>>>>> outside as 100.100.100.100. nat-control is not configured. No other NAT >>>>>> configurations are present >>>>>> >>>>>> I am running a traceroute from R1 to 100.100.100.100 and seeing what >>>>>> I get with "inspect icmp error" not configured and then with it >>>>>> configured. Here are my results: I am only going to focus on the ICMP >>>>>> time-exceeded message coming back from R2 >>>>>> >>>>>> ICMP ERROR INSPECTION DISABLED >>>>>> ------------------------------------------------------------- >>>>>> >>>>>> - R1 Traces to 100.100.100.100 >>>>>> IP SRC: 100.100.100.1 >>>>>> IP DST: 100.100.100.100 >>>>>> UDP SRC: 49224 >>>>>> UDP DST: 33434 >>>>>> >>>>>> - ASA NATs DST 100.100.100.100 --> 10.10.3.100, sends to R2 >>>>>> - ASA creates a connection for this UDP packet >>>>>> >>>>>> - R2 decrements TTL --> 0 sends ICMP time-exceeded back towards R1 >>>>>> IP SRC: 10.10.10.2 >>>>>> IP DST: 100.100.100.1 >>>>>> ICMP PAYLOAD ORIGINAL IP SRC: 100.100.100.1/49224 >>>>>> ICMP PAYLOAD ORIGINAL IP DST: 10.10.3.100/33434 >>>>>> >>>>>> - ASA receives ICMP unreachable and doctors the packet >>>>>> automatically because it matches the previous UDP connection >>>>>> - ICMP PAYLOAD SRC 100.100.100.1/49224 and DST >>>>>> 10.10.3.100/33434pairs match the existing UDP connection >>>>>> - Therefore, the packet is NAT'd and the ICMP payload doctored >>>>>> like so... >>>>>> >>>>>> IP SRC: 100.100.100.100 <--- NAT the source to hide the >>>>>> intermediate hop IP address >>>>>> IP DST: 100.100.100.1 >>>>>> ICMP PAYLOAD ORIGINAL IP SRC: 100.100.100.1/49334 >>>>>> ICMP PAYLOAD ORIGINAL IP DST: 100.100.100.100/33434 <--- changed >>>>>> to hide the real server IP address >>>>>> >>>>>> - Note that this doctoring process obviously has nothing to do with >>>>>> "inspect icmp error" since we have it disabled. >>>>>> >>>>>> >>>>>> ICMP ERROR INSPECTION ENABLED >>>>>> ------------------------------------------------------------- >>>>>> >>>>>> - R1 Traces to 100.100.100.100 >>>>>> IP SRC: 100.100.100.1 >>>>>> IP DST: 100.100.100.100 >>>>>> UDP SRC: 49224 >>>>>> UDP DST: 33434 >>>>>> >>>>>> - ASA NATs DST 100.100.100.100 --> 10.10.3.100, sends to R2 >>>>>> - ASA creates a connection for this UDP packet >>>>>> >>>>>> - R2 decrements TTL --> 0 sends ICMP time-exceeded back towards R1 >>>>>> IP SRC: 10.10.10.2 >>>>>> IP DST: 100.100.100.1 >>>>>> ICMP PAYLOAD ORIGINAL IP SRC: 100.100.100.1/49224 >>>>>> ICMP PAYLOAD ORIGINAL IP DST: 10.10.3.100/33434 >>>>>> >>>>>> - ASA receives ICMP unreachable >>>>>> - ICMP PAYLOAD SRC 100.100.100.1/49224 and DST >>>>>> 10.10.3.100/33434pairs match the existing UDP connection >>>>>> >>>>>> IP SRC: 10.10.10.2 <--- No NAT, expose the IP address of the >>>>>> intermediate hop >>>>>> IP DST: 100.100.100.1 >>>>>> ICMP PAYLOAD ORIGINAL IP SRC: 100.100.100.1/49334 >>>>>> ICMP PAYLOAD ORIGINAL IP DST: 100.100.100.100/33434 <--- changed >>>>>> to hide real server IP address >>>>>> Therefore, the intermediate hop IP is exposed but the real server >>>>>> IP still remains hidden. >>>>>> >>>>>> >>>>>> Now, here is where my confusion is. According to the command >>>>>> reference for this command, here is what should happen when it is >>>>>> enabled: >>>>>> >>>>>> When enabled, the ICMP error inspection engine makes the following >>>>>>> changes to the ICMP packet: >>>>>>> >>>>>>> •In the IP Header, the NAT IP is changed to the Client IP >>>>>>> (Destination Address and Intermediate Hop Address) and the IP checksum >>>>>>> is >>>>>>> modified. >>>>>>> >>>>>>> •In the ICMP Header, the ICMP checksum is modified due to the >>>>>>> changes in the ICMP packet. >>>>>>> >>>>>>> •In the Payload, the following changes are made: >>>>>>> >>>>>>> –Original packet NAT IP is changed to the Client IP >>>>>>> >>>>>>> –Original packet NAT port is changed to the Client Port >>>>>>> >>>>>>> –Original packet IP checksum is recalculated >>>>>>> >>>>>> >>>>>> I am having a real hard time making sense of "NAT IP" and "Client IP" >>>>>> in these statements. Regarding the IP header comment there -- You can >>>>>> see >>>>>> that nothing was changed in my example. The source/destination IP >>>>>> address >>>>>> in the ICMP time exceeded messages going from R2 back to R1 never >>>>>> changed. >>>>>> Let's imagine I had nat-control on for a second though and that I did >>>>>> have >>>>>> a static NAT translation for R2 10.10.10.2 going to 100.100.100.2. In >>>>>> this >>>>>> case it would make some sense. I think what it is saying is that if I >>>>>> did >>>>>> have a translation the source IP of the ICMP error coming back from R2 to >>>>>> R1 would be changed to the mapped address. Since in my case I am not >>>>>> doing >>>>>> NAT nothing changes. Fair enough >>>>>> >>>>>> Now, the part about the ICMP payload is very confusing. It says the >>>>>> "original packet NAT IP is changed to the client IP". Again, not sure >>>>>> what >>>>>> they mean by NAT IP and client IP but I know what I see in my packet >>>>>> sniffer. As I showed, in the ICMP payload the original IP destination >>>>>> address gets changed from the real IP address to the mapped IP address of >>>>>> the server. This makes sense, because this way the real IP of the server >>>>>> is still hidden, but the real IP address of the intermediate hop is seen. >>>>>> I just don't really get the whole "NAT IP / Client IP" thing there. >>>>>> >>>>>> If anybody can confirm my understanding of this topic or offer some >>>>>> insite, that would be great >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Joe Astorino >>>>>> CCIE #24347 >>>>>> http://astorinonetworks.com >>>>>> >>>>>> "He not busy being born is busy dying" - Dylan >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Joe Astorino >>>>> CCIE #24347 >>>>> http://astorinonetworks.com >>>>> >>>>> "He not busy being born is busy dying" - Dylan >>>>> >>>>> >>>>> _______________________________________________ >>>>> For more information regarding industry leading CCIE Lab training, >>>>> please visit www.ipexpert.com >>>>> >>>>> Are you a CCNP or CCIE and looking for a job? Check out >>>>> www.PlatinumPlacement.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Joe Astorino >>> CCIE #24347 >>> http://astorinonetworks.com >>> >>> "He not busy being born is busy dying" - Dylan >>> >>> >> > > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
