Perhaps because there was no NAT for the initial UDP packet going to 2.2.2.2 the inherent ICMP security algorithm in the ASA decides not to NAT the return traffic, regardless of the fact that there is a static NAT...or maybe it NATs it to itself (like a static identity NAT). I sure wish I knew for sure though!
On Wed, Feb 15, 2012 at 10:59 AM, Peter Debye <[email protected]> wrote: > 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= > [email protected]> > >> >> > 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 > > > -- 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
