Just to be clear: FW# sh ip System IP Addresses: Interface Name IP address Subnet mask Method Ethernet0/0 inside 192.168.151.38 255.255.255.252 CONFIG Ethernet0/1 outside 192.168.151.41 255.255.255.252 CONFIG
Current IP Addresses: Interface Name IP address Subnet mask Method Ethernet0/0 inside 192.168.151.38 255.255.255.252 CONFIG Ethernet0/1 outside 192.168.151.41 255.255.255.252 CONFIG ! NO ROUTE EXISTS FOR THE MAPPED ADDRESS FW# sh route | i 192.168.10 S 192.168.10.96 255.255.255.248 [1/0] via 192.168.151.42, outside S 192.168.10.88 255.255.255.248 [1/0] via 192.168.151.42, outside ! STATIC ROUTE EXISTS POINTING OUTSIDE FOR THE REAL IP FW# sh route | i 10.12 S 10.12.20.56 255.255.255.255 [1/0] via 192.168.151.42, outside ! DEFAULT ROUTE EXISTS POINTING INSIDE FW# sh route | i 0.0.0.0 Gateway of last resort is 192.168.151.37 to network 0.0.0.0 D* 0.0.0.0 0.0.0.0 [90/30720] via 192.168.151.37, 1193:02:47, inside ! STATIC OUTSIDE NAT static (outside,inside) 192.168.10.241 10.12.20.56 netmask 255.255.255.255 This functions. If I remove the static route to the real IP it does not function at all. If I remove the static route to the real IP and add a static route pointing outside for the mapped IP it does not function at all. Hope that clarifies my problem. On Mon, Apr 22, 2013 at 5:01 PM, Joe Astorino <[email protected]>wrote: > Thanks Piotr. So in this case I do not have a route for the mapped > address anywhere. I only have a default-route pointing inside. In my > case, based on what you are saying the following would happen > > - routing is checked for 192.168.10.241. There is no route. Default > route matches pointing INSIDE > - static translation tells the ASA to forward the packet OUTSIDE > - packet is virtually sent to egress interface and it checks routing > table. Default route again points INSIDE. > - Packet is dropped. > > That is not what I'm seeing though. When I have a specific route for the > real address and no specific route at all (except the default) for the > mapped address it works > > > On Mon, Apr 22, 2013 at 4:53 PM, Piotr Matusiak <[email protected]> wrote: > >> Hi Joe, >> >> First routing is checked to see what is the egress interface so that the >> ASA can guess if a connection is Inbound or Outbound. Then, if you have >> xlate for that packet, the xlate will tell ASA where to forward packet to. >> Finally, when the packet is virtually sent to the egress interface (based >> on the xlate) ASA resolves L3 next hop, and here it checks routing table >> again. If the route is different, the packet is dropped. Check it with 'sh >> asp drop'. >> >> Regards, >> Piotr Matusiak >> >> >> >> On 4/22/13 9:50 PM, Joe Astorino wrote: >> >> 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
_______________________________________________ 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
