Hmmmmm....apologies as that article is specifically for IOS routers and not the ASA. I can't imagine why the ASA would behave differently. Anybody?
On Mon, Apr 22, 2013 at 4:46 PM, Joe Astorino <[email protected]>wrote: > Also, please see > http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml > > This clearly outlines that when going from inside --> outside routing > should be performed first. Seems that is true, except in the specific case > I posted about (outside NAT) > > > On Mon, Apr 22, 2013 at 4:44 PM, Joe Astorino > <[email protected]>wrote: > >> Hi Kevin, >> >> Thanks for the reply, but your example is talking about what would happen >> on an outside --> inside flow. In that case what you are saying makes >> sense. However, when going from inside to outside I believe the rules >> generally are different. >> >> I think that for basic static NAT from inside --> outside indeed routing >> is performed first. You can see this in the output of a packet-trace and >> most documentation I've seen shows route lookup happening first when going >> inside --> outside. >> >> It is only in this specific case (inside to outside flow with outside >> static NAT) that I am puzzled. >> >> >> On Mon, Apr 22, 2013 at 4:38 PM, Kevin Sheahan <[email protected]>wrote: >> >>> Hi Joe, >>> >>> For ASA code in both pre 8.3 and 8.3+, routing will be post-NAT. I don't >>> know the exact reasoning for this but I can speculate that it is to both >>> route based on 'real ip' (simplifies routing table) as well as to allow for >>> simpler implementation of 'route-lookup' NAT function. The order of >>> operations changes between pre 8.3 and 8.3+ between the "Access-Control" >>> and "NAT" steps (ACL done before nat in pre-8.3, NAT done before ACL in >>> 8.3+). >>> >>> If routing were to happen pre-NAT, than consider the following example: >>> >>> >>> - You have 12.232.232.0/24 address space. >>> - Your outside interface is assigned 12.232.232.80. >>> - The whole 12.232.232.0/24 network is then directly connected to >>> the outside interface. So any incoming packet being routed first would >>> want >>> to hairpin and not reach its correct destination. Additionally, RPF check >>> would fail for NAT (unless NAT specifies outside,outside) so the packet >>> would be dropped. >>> - Because, in reality, routing happens after NAT – An incoming >>> packet can be un-nat'ed to, for example, DMZ address 192.168.232.x and >>> routed accordingly. >>> >>> Hope I was helpful. >>> >>> Good studies, >>> >>> Kevin Sheahan >>> >>> From: Joe Astorino <[email protected]> >>> Date: Monday, April 22, 2013 3:50 PM >>> To: OSL Security <[email protected]> >>> Subject: [OSL | CCIE_Security] 8.2 static outside NAT >>> >>> I could really use some clarification here. Here is my setup >>> >>> ASA running 8.2 code. nat-control is not enforced. Requirement is that >>> traffic destined to 192.168.10.241 on the inside will have the destination >>> translated to 10.12.20.56 on the outside. Conversely, traffic sourced from >>> 10.12.20.56 on the outside will have it's source translated to >>> 192.168.10.241 on the inside. >>> >>> My solution >>> >>> static (outside,inside) 192.168.10.241 10.12.20.56 netmask >>> 255.255.255.255 >>> >>> >>> Now, I assumed going from inside --> outside routing happens first. So, >>> I added a route like so >>> route (outside) 192.168.10.241 255.255.255.255 outside_next_hop >>> >>> This failed to work. Only when I add a static route pointing outside >>> for the REAL address does this work. This is baffling me. >>> >>> Also, when running packet-tracer the first step is UN-NAT which I've >>> never heard of before and can't find much information on. Can anybody >>> explain why routing is happening POST nat here??? >>> -- >>> 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 > -- 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
