Joe, if you do a packet-trace through asa with icmp unreachable packet you will see that NAT is always attempted after icmp error fixup. I only can say that depending on the result of the fixup, NAT can be bypassed in some cases. For example, if the fixup had already fixed the srcIP of the icmp packet itself, then there's no sense in doing NAT on it. ============================================
On 15 February 2012 15:19, Joe Astorino <[email protected]> wrote: > Hi Peter, > > Yes, you are exactly right, it works exactly backwards to the "normal" > situation, and that is exactly why I am confused about what is actually > going on in that specific setup. I have labbed it over and over and my > results are exactly as you say. I am trying to determine WHY. Like I said > before I think that the reason why when the feature is disabled we see the > real IP address of R2's transient link is because although we have a static > nat for R2's transient link, the fact that the icmp error message is treated > as return traffic in an initial flow to 2.2.2.2 instead of unsolicited > traffic from 10.2.2.2, it basically bypasses that static NAT. > > Do you know if this is true or am I missing something about how the > technology works? Thanks for your help. > > > On Wed, Feb 15, 2012 at 6:19 AM, Peter Debye <[email protected]> wrote: >> >> Hi Joe, >> in the example topology that you propose the behaviour >> of asa is the opposite to that we discussed initially. >> For your topo: >> R1---ASA---R2 >> R1/ASA: 100.100.100.0/24 <--- ASA "outside" >> ASA/R2: 10.10.10.0/24 <--- ASA "inside" interface >> R2 Lo0: 2.2.2.2 >> static (i,o) 100.100.100.2 10.10.10.2 >> >> - with inspect icmp error DISABLED you will see in the trace >> from R1 to 2.2.2.2 the answer from REAL R2 address, 10.10.10.2; >> - with inspect icmp error ENABLED you will see the answer from >> natted R2 address, 100.100.100.2. >> I.e., the internal host's IP is revealed in clear with icmp error fixup >> disabled, while it should be hidden by default. >> >> While this might be seen as a defect of implementation or software >> bug, I would not consider it as such. The thing is, asa was not designed >> for ccie training only, but more for real life implementations. >> And in real life the typical situation will be to trace to the >> inside host (natted of course), while the inside transient links are >> not natted (our initial discussion). That one is a typical situation for >> which icmp error fixup was designed, and it works as expected. >> In your example the things are somewhat upside down: the target host >> (2.2.2.2) >> is not natted, but the transient link is (10.10.10.0). I am not >> surprised that in this situation the fixup works differently. >> >> Anyway, we must thank asa that at least the icmp error packet is passed >> to tracer in both cases. There are real life situations when the >> legitimate >> icmp error packet is blocked by asa, and you can do nothing about that... >> >> ======================================================= >> >> On 14 February 2012 20:43, Joe Astorino <[email protected]> wrote: >> > Hey Pete! Thanks for your reply. Everything you are saying makes sense >> > based on my studies and labbing, but one nagging question remains to me: >> > Check out this example I posted earlier: >> > >> > R1---ASA---R2 >> > >> > R1/ASA: 100.100.100.0/24 <--- ASA "outside" >> > ASA/R2: 10.10.10.0/24 <--- ASA "inside" interface >> > R2 Lo0: 2.2.2.2 >> > static (i,o) 100.100.100.2 10.10.10.2 >> > >> > When I have the icmp error inspectino DISABLED and I trace from R1 to >> > 2.2.2.2 the first (and only) hop comes back as 10.10.10.2 -- the REAL IP >> > address of the R2 interface facing the ASA. This despite of the fact >> > that I >> > have a static NAT for 10.10.10.2 translating to the global 100.100.100.2 >> > as >> > you see there. >> > >> > My thought is this, but I want to confirm: >> > >> > - R1 sends the UDP packets towards 2.2.2.2 >> > - ASA has no NAT rules for this, so it forwards it on as is >> > - R2 gets the UDP packet and replies with an ICMP unreachable. This >> > packet >> > is sourced from 10.10.10.2 and destined to 100.100.100.1 >> > - The ICMP payload of this packet has a record of the original IP and >> > UDP >> > header that looks like this: 10.10.10.2:abcde --> 2.2.2.2:33434 >> > - When the ASA receives this ICMP error packet, it looks at the ICMP >> > payload >> > and based on that checks the xlate table for an existing flow from >> > 10.10.10.2 --> 2.2.2.2. There was never any translation so therefore it >> > does NOT nat the packet. >> > >> > This is still a bit fuzzy because despite all of that, the ICMP error >> > from >> > R2 --> R1 is still sourced from 10.10.10.2 and I still have a static NAT >> > for >> > that. Why is it not translated to 100.100.100.2 regardless? The only >> > thing >> > I can think of is that the ICMP error inspection that is happening as >> > you >> > say by default overrides the static NAT. Basically, the ASA sees the >> > ICMP >> > error message as a reply in the flow that originated from 100.100.100.1 >> > --> >> > 2.2.2.2 and NOT as an unsolicited packet sourced from 10.10.10.2. Even >> > though it is sourced from 10.10.10.2 and I clearly have a translation >> > for >> > that, no translation is done. >> > >> > On Tue, Feb 14, 2012 at 1:16 PM, Peter Debye <[email protected]> wrote: >> >> >> >> SORRY FOR THE TYPO IN THE LAST PARAGRAPH - corrected. >> >> >> >> On 14 February 2012 19:07, Peter Debye <[email protected]> wrote: >> >> > Let me tell you guys that ICMP error packet inspection is an inherent >> >> > part of the asa security algorithm, and is ALWAYS performed on these >> >> > packets whether "inspect icmp error" is enabled or not. >> >> > (that is why I'd prefer the older "fixup icmp error" term as less >> >> > confusing.) >> >> > >> >> > When asa receives the icmp error packet it should first check whether >> >> > this one can be mathed with the established flow or not. In other >> >> > words, >> >> > whether this packet comes back in response to a real offending packet >> >> > seen >> >> > by asa or it is a spoofed one. For this the first check is always to >> >> > look inside the icmp error payload and try to match the IPs inside it >> >> > with an existing xlate >> >> > slot. This is done irrespective of "inspect icmp error". If the slot >> >> > is >> >> > found >> >> > then the icmp payload will be fixed (doctored) in accord with it: >> >> > e.g., >> >> > the >> >> > source IP of the enacapsulated offending packet header will be >> >> > changed. >> >> > >> >> > The second step now depends on the config of the "inspect icmp err": >> >> > - if NOT enabled then the source IP of the ICMP packet itself is also >> >> > changed >> >> > in accord with the xlate slot. This is also part of the asa security >> >> > algo: >> >> > all inside hosts' src IPs will show as if sent by final host. This >> >> > way >> >> > the internal path is hidden from the tracer. In the trace output you >> >> > will >> >> > then normally see several lines with the same IP. >> >> > But if "inspect icmp err" is enabled, this step is omitted, and the >> >> > intermediate hosts' src IPs are seen in clear. >> >> > >> >> > cheers. >> >> > ============================================== >> >> > >> >> > >> >> > >> >> > >> >> > ---------------------------------------------------------------------- >> >> > >> >> > Date: Tue, 14 Feb 2012 21:44:01 +0530 >> >> > From: Kingsley Charles <[email protected]> >> >> > To: Joe Astorino <[email protected]> >> >> > Cc: OSL Security <[email protected]> >> >> > Subject: Re: [OSL | CCIE_Security] inspect icmp error >> >> > Message-ID: >> >> > >> >> > <CAHs0B04SX38kFcGXK=fzj8d5g4yy6yvbkfdxpxjxvqadqn0...@mail.gmail.com> >> >> > Content-Type: text/plain; charset="windows-1252" >> >> > >> >> > 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 >> >> _______________________________________________ >> >> 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
