Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
New Member

Strange NAT behavior

Hi Guys,

Can someone explain me why this is happing for this configuration? I have NAT statement for 10.231.7.128 255.255.255.192 subnet. Which should translate/PAT everything going from inside interface to dmz2 with the dmz2 interface (check config). But if I try to run packet-trace from inside to dmz2 it will automatically try to  NAT to the outside interface but still goes out on the dmz2 interface (check the packet-tracer output). Why does the ASA do this? It should only be hit by the NAT statement for the dmz2 because the traffic is going to the dmz2 interface. 

Version 8.0(2)

ASA# show run nat

nat (inside) 0 access-list stads_nat0_acl (the subnet is not included in this list)

nat (inside) 1 10.231.7.128 255.255.255.192

ASA# show run route | in 90.90.90.90                              

route Dmz2 90.90.90.90 255.255.255.255 192.168.2.4 1 (routed via dmz2)

global (outside) 1 80.80.80.80

global (outside) 2 xx.xx.xx.xx netmask 255.255.255.255

global (Dmz1) 1 yy.yy.yy.yy

global (Dmz2) 1 interface

global (Dmz3) 1 interface

global (Dmz4) 1 interface

global (Dmz5) 1 interface

global (Dmz8) 1 192.168.201.0 netmask 255.255.255.0

global (Dmz9) 1 interface

ASA# packet-tracer input inside tcp 10.231.7.135 5554 90.90.90.90

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   90.90.90.90    255.255.255.255 Dmz2

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_acl in interface inside

access-list inside_acl extended permit ip any any

Additional Information:

Phase: 4     

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

class-map inspection_default

match default-inspection-traffic

policy-map global_policy

class inspection_default

  inspect http

service-policy global_policy global

Additional Information:

Phase: 6

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (inside) 1 10.231.7.128 255.255.255.192

  match ip inside 10.231.7.128 255.255.255.192 outside any

    dynamic translation to pool 1 (80.80.80.80) Why??

    translate_hits = 0, untranslate_hits = 0

Additional Information:

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 12, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: Dmz2

output-status: up

output-line-status: up

Action: allow

14 REPLIES
Super Bronze

Re: Strange NAT behavior

Hi,

The above "packet-tracer" outputs NAT configuration is not actually applied.

If it was applied you would see the actual translation created in the "Additional Information" section of the Phase 6 output.

So seems to me that no translation is applied to the traffic described in the "packet-tracer" command used.

That again raises the question why the Dynamic PAT you mention is not applied.

I don't see any other reason why it would not except that the IP address you use as source in the "packet-tracer" is the broadcast IP address for the subnet that you have specified in the "nat" statement.

Could you for examples sake take a "packet-tracer" output with the source IP address 10.231.7.134

Is there actually a network bigger than /29 behind "inside" or why would traffic be coming from an IP address that should not be configured on any host? (broadcast address)

- Jouni

Super Bronze

Re: Strange NAT behavior

Hi

Don't know why but I must have completely looked the network mask wrong since its not /29 so the above situation that I mentioned naturally does not apply.

Naturally it still raises the question why does it not match the configuration at all even though its showing route lookup for dmz2

- Jouni

New Member

Re: Strange NAT behavior

Hi Roger

Please Check wether DMZ2 intreface is physially up or not.

In case of down all corresponding routes via this interface will not take effect that may be a cause this !

New Member

Re: Strange NAT behavior

Status is UP and protocol is UP

Hall of Fame Super Blue

Strange NAT behavior

Roger

Is that your full NAT config as posted in terms of dynamic NAT ?

Jon

New Member

Re: Strange NAT behavior

Yes, thats my entire dynamic NAT statements. But I have lot of static NAT`s too. But cannot see that should affect this.

Super Bronze

Strange NAT behavior

Hi,

Do you have the option to try the command

nat (inside) 1 0.0.0.0 0.0.0.0

In addition to the current one existing on the device or will this break some current setup. I mean since the above command would start looking for a matching "global" for every source address behind "inside" unless there was an overriding NAT present like Static NAT/PAT (normal/policy) or NAT0 perhaps.

Just seems strange that it wont match the Dynamic PAT even though there is a configuration that matches for these source and destination interfaces.

- Jouni

Super Bronze

Strange NAT behavior

Also,

Was wondering what the "security-level" of the interfaces are.

Though I would assume that your internanl interface is 100. Was thinking if it could be related to having the source interface at lower "security-level" than the destination.

- Jouni

New Member

Re: Strange NAT behavior

No difference after adding that nat statement. Its going from lower security level to higher security level.

same-securiy-traffic permit inter and intra-interface are applied. 

New Member

Re: Strange NAT behavior

This must be CCIE level of question

Super Bronze

Re: Strange NAT behavior

Hi,

So you said that the "inside" is of lower "security-level" than the "dmz2" ?

Then the only way the "nat" statement would work if it had

nat (inside) 1 10.231.7.128 255.255.255.192 outside

The "outside" parameter is needed when the source is lower security than the destination and you want to do a Dynamic translations.

Here is quote about the parameter in the Command Reference

outside

(Optional) If this interface is on a lower security level than the interface you identify by the matching global statement, then you must enter outside. This feature is called outside NAT or bidirectional NAT.

Here is link to the Command Reference section on the "nat" command

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/no.html#wp1756533

- Jouni

New Member

Re: Strange NAT behavior

If I do that then result seems to be changed.

ASA(config)# packet-tracer input inside tcp 10.231.7.135 5554 90.90.90.90 80

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   90.90.90.90    255.255.255.255 Dmz2

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_acl in interface inside

access-list inside_acl extended permit ip any any

Additional Information:

Phase: 4     

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

class-map inspection_default

match default-inspection-traffic

policy-map global_policy

class inspection_default

  inspect http

service-policy global_policy global

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside) 1 10.231.7.128 255.255.255.192 outside

  match ip inside 10.231.7.128 255.255.255.192 Dmz2 any

    dynamic translation to pool 1 (192.168.2.1 [Interface PAT])

    translate_hits = 2, untranslate_hits = 0

Additional Information:

Dynamic translate 10.231.7.132/55547 to 192.168.2.1/1025 using netmask 255.255.255.255

Phase: 7

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (inside) 1 10.231.7.128 255.255.255.192

  match ip inside 10.231.7.128 255.255.255.192 outside any

    dynamic translation to pool 1 (80.80.80.80)

    translate_hits = 0, untranslate_hits = 0

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9     

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 1, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: Dmz2

output-status: up

output-line-status: up

Action: allow

Super Bronze

Strange NAT behavior

Hi,

Seems we posted at the same time.

Seems to me according to the above output that it would now match the correct Dynamic configuration.

But does the connection work normally from "inside" to "dmz2"?

Let me know if there is still some problem with it.

Please do remember to mark a reply as the correct answer if it answered your question.

- Jouni

Super Bronze

Strange NAT behavior

Hi,

Have you had the chance to try the above parameter in your "nat" configuration?

- Jouni

198
Views
0
Helpful
14
Replies
CreatePlease to create content