Outside NAT not working

[jtowry]

I have a server at 10.1.1.51 that is translated to 75.141.84.6 for all outbound connections. For connections to 10.5.20.103 the destination needs to be translated to 10.0.0.103.

object network PerrySrv-0-103

host 10.5.20.103

object network Perry-srv-orig-103

host 10.0.0.103

!

object network Orion-srv-ext

host 75.141.84.6

!

object network Orion-srv

host 10.1.1.51

!

nat (ITS_inside,ITS-outside) source static Orion-srv Orion-srv-ext destination static PerrySrv-0-103 Perry-srv-orig-103 no-proxy-arp

!

When I do a traceroute to the 10.0.0.103 from 10.1.1.51 the results are this:

Tracing route to 10.5.20.103 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.1.153

  2     1 ms     1 ms     1 ms  10.1.1.205

  3     1 ms     1 ms     1 ms  10.5.20.103

  4     2 ms     2 ms     2 ms  10.5.20.103

  5    39 ms    39 ms    39 ms  10.5.20.103

  6    40 ms    40 ms    40 ms  10.5.20.103

Trace complete.

Also RDP's to 10.0.0.103 do not work.

Thanks in advance!

Jeff

[Jouni Forss]

Hi,

Can you check if you have the ICMP Inspection enabled

The old commands you can use on the CLI directly to enable them are

fixup protocol icmp

fixup protocol icmp error

You can also go under your default "policy-map" configuration and add the following that will achieve the same

inspect icmp

inspect icmp error

Also, can you provide us with a "packet-tracer" output of that traffic?

packet-tracer input ITS_inside tcp 10.1.1.51 12345 10.5.20.103 3389

- Jouni

[jtowry]

Hi Jouni,

Thanks for the reply. I have changed the host I was trying to connect to 10.5.20.194. I can connect via RDP to the server 10.5.20.194 ok now. Why do the tracert replies all show 10.5.20.194 as the address for the hops past the firewall?

object network Orion-srv

host 10.1.1.51

!

object network Orion-srv-ext

host 75.141.84.6

!

object network PerryCo-194

host 10.5.20.194

!

object network PerryCo-194-ext

host 10.0.0.194

!

nat (ITS_inside,ITS-outside) source static Orion-srv Orion-srv-ext destination static PerryCo-194 PerryCo-194-ext no-proxy-arp

!

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny

  inspect esmtp

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect sip

  inspect xdmcp

  inspect icmp        <<<<<<

  inspect ip-options

PS> tracert -d 10.5.20.194

Tracing route to 10.5.20.194 over a maximum of 30 hops

  1     2 ms     8 ms     1 ms  10.1.1.153

  2     1 ms     1 ms     1 ms  10.1.1.205

  3     1 ms     1 ms     1 ms  10.5.20.194

  4     2 ms     2 ms     2 ms  10.5.20.194

  5    39 ms    39 ms    39 ms  10.5.20.194

  6    39 ms    39 ms    39 ms  10.5.20.194

Thanks.

RSA-DC-ASA-A/ITS# packet-tracer input ITS_inside tcp 10.1.1.51 12345 10.5.20.194

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (ITS_inside,ITS-outside) source static Orion-srv Orion-srv-ext destination static PerryCo-194 PerryCo-194-ext no-proxy-arp

Additional Information:

NAT divert to egress interface ITS-outside

Untranslate 10.5.20.194/3389 to 10.0.0.194/3389

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group ITS-inside in interface ITS_inside

access-list ITS-inside extended permit ip any4 any4

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (ITS_inside,ITS-outside) source static Orion-srv Orion-srv-ext destination static PerryCo-194 PerryCo-194-ext no-proxy-arp

Additional Information:

Static translate 10.1.1.51/12345 to 75.141.84.6/12345

Phase: 4

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (ITS_inside,ITS-outside) source static Orion-srv Orion-srv-ext destination static PerryCo-194 PerryCo-194-ext no-proxy-arp

Additional Information:

Phase: 8

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

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 9663156, packet dispatched to next module

Result:

input-interface: ITS_inside

input-status: up

input-line-status: up

output-interface: ITS-outside

output-status: up

output-line-status: up

Action: allow

sh local-host 10.1.1.51

  ICMP ITS-outside 10.5.20.194(10.0.0.194):0 ITS_inside  10.1.1.51:11, idle 0:00:00, bytes 192, flags

[Jouni Forss · Accepted solution]

Hi,

Can you add this

policy-map global_policy

class inspection_default

  inspect icmp error

It might be something related to the fact that the replys are coming from router hops between your ASA and the actual destination host since it will be the router in between that is sending the ICMP Error message.

I think the ICMP Error message Inspection might be needed

- Jouni

[jtowry]

Hi Jouni,

Thanks, the traceroutes are showing the right information now.

Jeff

[Marius Gunnerud]

The format of the twice NAT is as follows

nat (real_int,map_int) source static destination static

so from your nat command output above you have the destination objects swapped around.

Please amend the configuration to the following and test:

nat (ITS_inside,ITS-outside) source static Orion-srv Orion-srv-ext  destination static Perry-srv-orig-103 PerrySrv-0-103 no-proxy-arp

--

Please remember to rate and select a correct answer

[Jouni Forss]

Hi,

Seems to me that the traceroute in the original post is done towards IP address 10.5.20.103 and the other "object" is named so that it suggests that its the "object" for the original IP address.

To my understanding seeing the same IP address on each hop is related to the NAT configuration and the user might be missing ICMP Inspection (error) that would help with the hops between the source host and the actual traced destination host.

Though the original poster needs to clarify if there is some doubt to which of the destination IP addresses is the actual NAT IP address.

- Jouni