Hi Jay, I did not try swapping them because the real host machine does in fact live on the outside interface.If I were to swap them, that would indicate the real host lives on the inside network and that is not the case.
The article below seems to support the idea that when going from inside --> outside, NAT is actually done first to determine the outbound interface. If the outbound interface can be determined via NAT (as in my case with this static) , then that is the interface the packet ends up at. Only then is L3 routing table verified. If the destination cannot be determined by the NAT configuration, the global routing table is consulted. That would seem to explain this behavior. http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080ba9d00.shtml For the lazier here is the summary in the article. Of particular interest are steps 7-9. Notice how there is no mention at any point here that a route lookup is performed prior to the NAT translation. Here are the individual steps in detail: 1. Packet is reached at the ingress interface. 2. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one. 3. Cisco ASA will first verify if this is an existing connection by looking at its internal connection table details. If the packet flow matches an existing connection, then the access-control list (ACL) check is bypassed, and the packet is moved forward. If packet flow does not match an existing connection, then TCP state is verified. If it is a SYN packet or UDP packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged. 4. The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count will be incremented by one when the packet matches the ACL entry. 5. The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow, and the packet moves forward. Otherwise, the packet is dropped and the information is logged. 6. The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects each connection as per its pre-defined set of application-level functionalities. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged. Additional Security-Checks will be implemented if a CSC module is involved. 7. The IP header information is translated as per the NAT/PAT rule and checksums are updated accordingly. The packet is forwarded to AIP-SSM for IPS related security checks, when the AIP module is involved. 8. The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on global route lookup. 9. On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that will take the priority. 10. Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. Layer 2 rewrite of MAC header happens at this stage. 11. The packet is transmitted on wire, and Interface counters increment on the egress interface. On Mon, Apr 22, 2013 at 5:16 PM, Jay McMickle <[email protected]>wrote: > Did you try swapping the NAT statement (inside,outside). Proxy arp would > need to be enabled on the outside device for your NAT setup this way. > > If that doesn't fix it, what ARP address does your device on the outside > of the ASA see? I'm assuming this isn't a context firewall, but just a > single, routed mode, firewall. > > > Regards, > Jay McMickle- 3x CCNP (R&S,Security,Design), CCIE #35355 (R&S) > > > ------------------------------ > *From:* Joe Astorino <[email protected]> > *To:* OSL Security <[email protected]> > *Sent:* Monday, April 22, 2013 2:50 PM > > *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
_______________________________________________ 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
