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
