topic ASA 5510 DMZ and Inside cannot talk to one another in Network Security

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Mon, 11 Mar 2019 23:26:57 GMT

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.

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Thu, 05 Jul 2012 18:16:34 GMT

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

ASA 5510 DMZ and Inside cannot talk to one another

Gautam Bhagwandas — Thu, 05 Jul 2012 18:23:12 GMT

Adam,

A few inputs based on the configs:

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

global (dmz) 1 interface

Do you real need this statement?

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.

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.

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Thu, 05 Jul 2012 18:24:48 GMT

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

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

Adam Hudson — Thu, 05 Jul 2012 20:21:54 GMT

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

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

Adam Hudson — Thu, 05 Jul 2012 20:34:06 GMT

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!

ASA 5510 DMZ and Inside cannot talk to one another

rizwanr74 — Thu, 05 Jul 2012 20:48:27 GMT

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

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 01:03:47 GMT

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!

ASA 5510 DMZ and Inside cannot talk to one another

rizwanr74 — Fri, 06 Jul 2012 01:44:51 GMT

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

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 01:48:18 GMT

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.

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 01:51:19 GMT

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

ASA 5510 DMZ and Inside cannot talk to one another

rizwanr74 — Fri, 06 Jul 2012 02:05:23 GMT

""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

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 02:07:43 GMT

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

ASA 5510 DMZ and Inside cannot talk to one another

rizwanr74 — Fri, 06 Jul 2012 02:12:24 GMT

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

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 02:21:16 GMT

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.

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 02:34:12 GMT

But I need the flexibility of letting certain ports and ip addresses in and out of the DMZ, how do I do that now?

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

rizwanr74 — Fri, 06 Jul 2012 02:34:16 GMT

"But if that's right, how do I control what comes and goes from the dmz interface?"

More secure interface such as "inside" should be able to access dmz without any problem with the static that I showned you.

You can still add an ACL on the DMZ interface as shown below.

"But I need the flexibility of letting certain ports and ip addresses in and out of the DMZ, how do I do that now?

access-list dmz_incoming extended deny ip host 173.17.1.111 host 11.255.1.250

access-group dmz_incoming in interface dmz

Hope that helps.

thanks

Rizwan Rafeek

Message was edited by: Rizwan Mohamed

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 02:55:23 GMT

I must be doing something wrong then. I put in the following commands trying to block pings from coming "in" to the DMZ interface:

access-list dmz_access_in extended deny icmp any any

access-group dmz_access_in in interface dmz

Pings and packet tracer simulation are still successful. What am I missing?

ASA 5510 DMZ and Inside cannot talk to one another

Adam Hudson — Fri, 06 Jul 2012 03:06:11 GMT

For some reason my later post is posting higher than yours on my machine. Please see my comment, which appears to me as the post above yours.

ASA 5510 DMZ and Inside cannot talk to one another

rizwanr74 — Fri, 06 Jul 2012 03:06:39 GMT

"access-list dmz_access_in extended deny icmp any any

access-group dmz_access_in in interface dmz"

The above lines will work, if you ping from a dmz host, it will deny the traffic. meaning traffic will entre into dmz interface, from dmz zone.

if you want to control what can access from inside interface, you would do that same from inside interface.

hope that answers your questions.

thanks