Solved: ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson · ‎07-05-2012

I have several machines out in my DMZ and cannot get a ping going between them and anything on the inside of my network. I've even tried setting my access list attached to my DMZ to ip any any with no luck. Attached is my (sanitized) config. Any help is appreciated, everything looks good to me, but obviously something is wrong.

Thanks in advance.

rizwanr74 · ‎07-05-2012

I tested the below nat before on my ASA and it works fine. there is no ACL in the test lab, meaning it is more restrictive than having ACL.

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

thanks

View solution in original post

Adam Hudson · ‎07-05-2012

Packet tracer results running from DMZ to Inside:

SiteA-Firewall# packet-tracer input dmz icmp 173.17.1.4 0 0 11.2.1.23

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (inside,dmz) 11.2.1.0 11.2.1.0 netmask 255.255.255.0

nat-control

match ip inside 11.2.1.0 255.255.255.0 dmz any

static translation to 11.2.1.0

translate_hits = 1, untranslate_hits = 3

Additional Information:

NAT divert to egress interface inside

Untranslate 11.2.1.0/0 to 11.2.1.0/0 using netmask 255.255.255.0

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group dmz_access_in in interface dmz

access-list dmz_access_in extended permit icmp 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

description Internet_Netflow

class inspection_default

inspect icmp

service-policy global_policy global

Additional Information:

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (dmz) 1 173.17.1.0 255.255.255.0

nat-control

match ip dmz 173.17.1.0 255.255.255.0 dmz any

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

translate_hits = 0, untranslate_hits = 0

Additional Information:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

static (inside,dmz) 11.2.1.0 11.2.1.0 netmask 255.255.255.0

nat-control

match ip inside 11.2.1.0 255.255.255.0 dmz any

static translation to 11.2.1.0

translate_hits = 1, untranslate_hits = 3

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: dmz

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Adam Hudson · ‎07-05-2012

From inside to DMZ:

SiteA-Firewall# packet-tracer input inside icmp 11.2.1.23 0 0 173.17.1.4

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 173.17.1.0 255.255.255.0 dmz

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

description Internet_Netflow

class inspection_default

inspect icmp

service-policy global_policy global

Additional Information:

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: NAT

Subtype:

Result: ALLOW

Config:

static (inside,dmz) 11.2.1.0 11.2.1.0 netmask 255.255.255.0

nat-control

match ip inside 11.2.1.0 255.255.255.0 dmz any

static translation to 11.2.1.0

translate_hits = 2, untranslate_hits = 3

Additional Information:

Static translate 11.2.1.0/0 to 11.2.1.0/0 using netmask 255.255.255.0

Phase: 9

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,dmz) 11.2.1.0 11.2.1.0 netmask 255.255.255.0

nat-control

match ip inside 11.2.1.0 255.255.255.0 dmz any

static translation to 11.2.1.0

translate_hits = 2, untranslate_hits = 3

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: dmz

output-status: up

output-line-status: up

Action: allow

Gautam Bhagwandas · ‎07-05-2012

Adam,

A few inputs based on the configs:

a.

route outside 11.2.2.0 255.255.255.0 24.106.253.3 1

static (inside,dmz) 11.2.2.0 11.2.2.0 netmask 255.255.255.0

You have a static nat for real address on inside 11.2.2.0 but the route for it is via outside interface?

I would expect this to be:

route inside 11.2.2.0 255.255.255.0 24.106.253.3 1

b. Hoping that all the below 6 inside networks are being learnt via eigrp? The reason i asked is i don't see static routes for any of them.

nat (inside) 1 11.1.1.0 255.255.255.0

nat (inside) 1 11.2.1.0 255.255.255.0

nat (inside) 1 11.2.70.0 255.255.255.0

static (inside,dmz) 11.2.1.0 11.2.1.0 netmask 255.255.255.0

static (inside,dmz) 11.1.1.0 11.1.1.0 netmask 255.255.255.0

static (inside,dmz) 173.17.2.0 173.17.2.0 netmask 255.255.255.0

c.

global (dmz) 1 interface

Do you real need this statement?

d.

nat (inside) 0 access-list no_nat

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.8.0.0 255.255.255.0

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.2.1.0 255.255.255.0

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.1.1.0 255.255.255.0

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.2.2.0 255.255.255.0

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 173.17.2.0 255.255.255.0

The above 5 lines are not required at all. 173.17.1.0 is a DMZ network. It doesn't have to be included as a source in the access-list for a nat on the inside interface.

e.

nat (dmz) 0 access-list no_nat_dmz

I don't see any access-list like no_nat_dmz in the configuration.

If you can be more specific on the flow not working, i can probably give more inputs. But from the info provided so far, this is what i infer.

Adam Hudson · ‎07-05-2012

I apologize, that was an older santized config. The attached file is the most up to date config.

Adam Hudson · ‎07-05-2012

Gautam, a) b) and e) are different in the changed config.

c) Would this line cause problems if it was left in?

d) Explanation:

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.8.0.0 255.255.255.0

Site A's DMZ and Site C's main subnet

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.2.1.0 255.255.255.0

Site A's DMZ and Site A subnet

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.1.1.0 255.255.255.0

Site A's DMZ and Site A's main subnet

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 11.2.2.0 255.255.255.0

Site A's DMZ and Site B's main subnet

access-list no_nat extended permit ip 173.17.1.0 255.255.255.0 173.17.2.0 255.255.255.0

Site A's DMZ and Site B's DMZ

Thanks for you help so far!

rizwanr74 · ‎07-05-2012

Hi Adam,

Please remove these highlighted lines below.

static (inside,dmz) 11.2.1.0 11.2.1.0 netmask 255.255.255.0

static (inside,dmz) 11.1.1.0 11.1.1.0 netmask 255.255.255.0

static (inside,dmz) 11.2.2.0 11.2.2.0 netmask 255.255.255.0

static (inside,dmz) 173.17.2.0 173.17.2.0 netmask 255.255.255.0

static (inside,dmz) 11.8.0.0 11.8.0.0 netmask 255.255.255.0

static (inside,dmz) 11.2.70.0 11.2.70.0 netmask 255.255.255.0

nat (dmz) 0 access-list no_nat_dmz

Now copy this line and try it.

static (inside,dmz) 173.17.1.0 173.17.2.0 netmask 255.255.255.0

Let me know, if that helps.

thanks

Adam Hudson · ‎07-05-2012

Removed all of the bolded selections, no communication. Re-added just the "nat (dmz) 0 access-list no_nat_dmz", no communication.

You suggested addition is confusing, the 173.17.1.0 network is the dmz at this site/on this machine, the 172.17.2.0 network is the dmz at another site and while technically on the "inside" the subnet is not located at the site and not one of the zones I'm currently trying to get to talk to one another.

Anything else you can see wrong with the config? This seems to be a real stumper!

rizwanr74 · ‎07-05-2012

Hi Adam,

Please remote this as well.

static (inside,dmz) 173.17.1.0 173.17.2.0 netmask 255.255.255.0

Please remove this as well: "nat (dmz) 0 access-list no_nat_dmz",

Just add one one shown below.

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

Please update.

thanks

Rizwan Rafeek

Adam Hudson · ‎07-05-2012

I had a co-working check my config, he noticed the no_nat acl wasn't being applied to anything. We went through some old configs where the DMZ was still working, the command "nat (inside) 0 access-list no_nat" was present in some of those old configs.

I applied this command was able to ping, success! My question after that was "So what ACL actually controls what gets between the DMZ and the Inside interfaces?" I ran the following command to remove the dmz_access_in ACL from the device "clear configure access-list dmz_access_in" then I tried to ping again. I pinged the interface, which I reasoned I should still be able to because technically there's nothing coming "in" to the DMZ. But, when I pinged a machine inside the DMZ, I thought nothing would come back because there's no acl on DMZ letting things back "in" to the interface. Well that ping worked as well.

So, my question is, "Why does pinging stop when the ACL no_nat is removed, but it continues if the previous ACL is in play but the dmz_access_in ACL is removed?" additionally, "What does that dmz_access_in ACL control if anything? Because it doesn't appear to be controlling what goes "in" to that dmz interface."

Thanks.

Adam Hudson · ‎07-05-2012

If packet-tracer results are to be believed, my issue is not solved, they can ping, but when I simulate traffice coming out of a machine on the DMZ, it gets dropped. Results below:

SiteA-Firewall# packet-tracer input dmz icmp 173.17.1.4 0 0 11.2.1.23

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 11.2.1.0 255.255.255.0 inside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group dmz_access_in in interface dmz

access-list dmz_access_in 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

description Internet_Netflow

class inspection_default

inspect icmp

service-policy global_policy global

Additional Information:

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (dmz) 1 173.17.1.0 255.255.255.0

nat-control

match ip dmz 173.17.1.0 255.255.255.0 dmz any

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

translate_hits = 0, untranslate_hits = 0

Additional Information:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

nat-control

match ip inside any dmz any

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

translate_hits = 1, untranslate_hits = 0

Additional Information:

Result:

input-interface: dmz

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

rizwanr74 · ‎07-05-2012

""So what ACL actually controls what gets between the DMZ and the Inside interfaces?" Is to control what is permited to leave dmz.

Please follow the steps I posted in my very last post and upldate me.

thanks

Adam Hudson · ‎07-05-2012

Addition, the above results are with a "permit ip any any" as the only line of dmz_access_in.

rizwanr74 · ‎07-05-2012

I tested the below nat before on my ASA and it works fine. there is no ACL in the test lab, meaning it is more restrictive than having ACL.

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

thanks

Adam Hudson · ‎07-05-2012

I removed the line "nat (dmz) 0 access-list no_nat_dmz",

And added the line: static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0.0

The pings work through packet tracer. I'm a bit confused as to why though. If I understand right the static command you had me put in "maps" the 10.0.0.0 subnet on the dmz to that same network on the inside interface. But if that's right, how do I control what comes and goes from the dmz interface? Specifically since I don't have an acl controlling the show anymore.

Thanks for your help so far.