topic Re: Strange NAT behavior in Network Security

Strange NAT behavior

Roger Base — Tue, 12 Mar 2019 03:46:36 GMT

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

Re: Strange NAT behavior

Jouni Forss — Mon, 17 Feb 2014 14:37:17 GMT

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

Re: Strange NAT behavior

Jouni Forss — Mon, 17 Feb 2014 14:39:04 GMT

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

Re: Strange NAT behavior

gouravbathla — Mon, 17 Feb 2014 14:42:16 GMT

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 !

Strange NAT behavior

Jon Marshall — Mon, 17 Feb 2014 14:48:29 GMT

Roger

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

Jon

Re: Strange NAT behavior

Roger Base — Mon, 17 Feb 2014 14:54:34 GMT

Status is UP and protocol is UP

Re: Strange NAT behavior

Roger Base — Mon, 17 Feb 2014 14:55:54 GMT

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

Strange NAT behavior

Jouni Forss — Mon, 17 Feb 2014 16:52:58 GMT

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

Strange NAT behavior

Jouni Forss — Mon, 17 Feb 2014 18:30:14 GMT

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

Re: Strange NAT behavior

Roger Base — Mon, 17 Feb 2014 19:55:54 GMT

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.

Re: Strange NAT behavior

Roger Base — Tue, 18 Feb 2014 09:47:22 GMT

This must be CCIE level of question

Re: Strange NAT behavior

Jouni Forss — Tue, 18 Feb 2014 09:51:51 GMT

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

Re: Strange NAT behavior

Roger Base — Tue, 18 Feb 2014 11:44:26 GMT

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

Strange NAT behavior

Jouni Forss — Tue, 18 Feb 2014 11:44:31 GMT

Hi,

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

- Jouni

Strange NAT behavior

Jouni Forss — Tue, 18 Feb 2014 11:47:20 GMT

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