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
_______________________________________________ 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
