Also here is packet tracer output of this working. Please note step 1
"UN-NAT". Also note that in the case of this specific test, there is also
a static inside NAT going on so both the source and destination are being
translated. (source from 10.2.102.130 --> 10.194.102.130 and destination
from 192.168.10.241 --> 10.12.20.56)
FW# packet-tracer input inside icmp 10.2.102.130 8 0 192.168.10.241
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (outside,inside) 192.168.10.241 10.12.20.56 netmask 255.255.255.255
match ip outside host 10.12.20.56 inside any
static translation to 192.168.10.241
translate_hits = 6, untranslate_hits = 92
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.10.241/0 to 10.12.20.56/0 using netmask 255.255.255.255
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
static (inside,outside) 10.192.0.0 10.0.0.0 netmask 255.248.0.0
match ip inside 10.0.0.0 255.248.0.0 outside any
static translation to 10.192.0.0
translate_hits = 50279, untranslate_hits = 215917
Additional Information:
Static translate 10.0.0.0/0 to 10.192.0.0/0 using netmask 255.248.0.0
Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 10.192.0.0 10.0.0.0 netmask 255.248.0.0
match ip inside 10.0.0.0 255.248.0.0 outside any
static translation to 10.192.0.0
translate_hits = 50279, untranslate_hits = 215917
Additional Information:
Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (outside,inside) 192.168.10.241 10.12.20.56 netmask 255.255.255.255
match ip outside host 10.12.20.56 inside any
static translation to 192.168.10.241
translate_hits = 6, untranslate_hits = 92
Additional Information:
Phase: 8
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (outside,inside) 192.168.10.241 10.12.20.56 netmask 255.255.255.255
match ip outside host 10.12.20.56 inside any
static translation to 192.168.10.241
translate_hits = 6, untranslate_hits = 92
Additional Information:
Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 45200557, packet dispatched to next module
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
On Mon, Apr 22, 2013 at 5:06 PM, Joe Astorino <[email protected]>wrote:
> 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
>
--
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
