Port 80 denied by ACL even though all ACLs allow incoming traffic

Phill Johntony · ‎03-01-2015

I am trying to do something really simple here. Very bare config on my ASA 5505, but I cannot manage to translate port 80 to my web server in a DMZ.

I have my webserver in a DMZ with security level 50, subnet 10.0.12.80/25. So I am trying to NAT translate port 80 from the outside interface to port 80 of the private webserver ip address, 10.0.12.4.

I am unable to access the web server externally, and I see a message in the log:

TCP access denied by ACL from 88.198.46.51/43807 to outside:107.10.62.33/80

The thing is the only ACLs that I have currently make all interfaces wide open, I have allow any any on all interfaces incoming. So why is this port translation failing?

The result in packet tracer shows the same thing.

packet-tracer input outside tcp 8.8.8.8 80 107.10.62.33 80 detail$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   107.10.62.33     255.255.255.255 identity

Phase: 2
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xa8a76028, priority=1, domain=nat-per-session, deny=true
        hits=11154, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
        input_ifc=any, output_ifc=any

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xaccd5e20, priority=0, domain=permit, deny=true
        hits=594, user_data=0x9, cs_id=0x0, use_real_addr, flags=0x1000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Please see my attached config.

Karsten Iwen · ‎03-02-2015

Your NAT-config is not as it should be.

1) The general dynamic NAT/PAT should always be at the end:

no nat (inside,outside) source dynamic any interface description NAT Overload for inside network
no nat (DMZ,outside) source dynamic any interface description NAT Overload for dmz network
nat (inside,outside) after-auto source dynamic any interface description NAT Overload for inside network
nat (DMZ,outside) after-auto source dynamic any interface description NAT Overload for dmz network

2) The next line is not even needed and can be removed:

no nat (inside,DMZ) source static obj-10.0.1.0 obj-10.0.1.0 destination static obj-10.0.12.0 obj-10.0.12.0 description Static NAT inside to/from dmz

Jon Marshall · ‎03-02-2015

Hi Karsten

Are you saying that because there is a dynamic entry on the DMZ it is taking precedence over the static entry ?

I only ask as we (Marvin, Jouni and myself) had a discussion about this recently in the VIP forum because of a similar post a while back.

Not trying to catch you out I just want to understand this fully as I am currently getting up to speed on post 8.3 NAT.

Jon

Karsten Iwen · ‎03-02-2015

Yes, the NAT-rules are used strictly top down (which btw. is not the order you see in "sh run".

The two lines in question are in section one and although they are dynamic rules, they match traffic coming in. With that, the ASA will never get to the object-NAT in section 2.

Thats the reason the NATs are often defined to be as the following:

1) Section One

all the exemptions that have to match always. For example that VPN-traffic should not be translated.

2) Section Two

All general NAT rules. And port-forwardings for the servers.

3) Section Three

Here we have all dynamic rules to get to the Internet.

If it is configured that way, there is not much that can go wrong.

Jon Marshall · ‎03-02-2015

Karsten

Okay the conversation I was referring to was about a static and dynamic in section 2.

I understand this is different ie. the dynamic is in section 1.

But I'm not understanding when you say -

and although they are dynamic rules, they match traffic coming in.

I thought dynamic rules didn't do that. I am going off 8.2 and earlier but if a connection is made from outside to the dmz I would have thought only the static could be matched.

This would create an xlate.

So I guess I have two questions -

1) are you saying with no existing xlates for the dmz server an inbound connection from outside would match the dynamic rule ?

2) if you aren't saying that and it would match the static does the return traffic from the web server match the dynamic rule because it is in section 1 and not 2 or does the traffic simply match the xlate that was created for inbound traffic.

Jon

Karsten Iwen · ‎03-03-2015

Hi Jon,

>I thought dynamic rules didn't do that. I am going off 8.2 and earlier but if a
> connection is made from outside to the dmz I would have thought only the
> static could be matched.

That's the same I thought for a very long time. And I don't have an explanation why it works this way. But it's quite easy to observe that with a dynamic PAT-rule in section 1 (like in this problem) the ASA never gets to the correct NAT-rule in section 2.

Jon Marshall · ‎03-03-2015

Hi Karsten

Could it be that it uses the static rule on the way in but then tries to use the dynamic rule on the way out as opposed to it using the dynamic rule on the way in if you see what I mean ?

I would have thought it would use the static both ways to be honest but I am happy to accept your version as I don't have anything to test with.

If it is using the static on the way in but the dynamic on the way out that must mean it is ignoring an already created xlate.

I am now totally confused :-)

Jon

Karsten Iwen · ‎03-03-2015

> Could it be that it uses the static rule on the way in but then tries to use the dynamic
> rule on the way out as opposed to it using the dynamic rule on the way in if you see
> what I mean ?

That's what I also thought at the beginning. But:

Using TCP-Dump shows that the initial packet doesn't leave the ASA.
The packet-tracer would show the usage of the static PAT which is not the case.

> I am now totally confused :-)

Mission completed ... ;-)

Jon Marshall · ‎03-03-2015

Karsten

Totally lost now :-)

How can a dynamic entry know which IP to translate to ?

If the first packet is from the outside with a destination IP of the outside interface how can the ASA know which real IP to translate that to. It could be a real IP on the dmz, it could be on the inside etc.

It cannot possibly work that out using a dynamic translation.

Perhaps I have misunderstood what you are saying but the firewall would need to be telepathic for that to work surely :-)

Jon

Karsten Iwen · ‎03-03-2015

I don't think that a translation is build (I have to evaluate that). As you say, there is not enough information to build that XLATE. But still, the ASA reacts on that inbound packet and does some NAT (Phase2 above) which restricts the ASA from reaching the correct NAT-Rule.

Jon Marshall · ‎03-03-2015

Karsten

I don't think that a translation is build (I have to evaluate that).

I think this is the bit I missed.

I was so confused I posted back into the VIP forum about it and Jouni kindly ran a quick test and you are absolutely spot on.

The dynamic NAT/PAT does take precedence but it can't build an entry because it has no way of knowing what the real IP is so the connection simply fails.

I was assuming you were saying the connection worked which you weren't so my fault entirely.

Post 8.3 is a lot more complicated than it used to be :-)

Jon

Karsten Iwen · ‎03-03-2015

> I was assuming you were saying the connection worked which you weren't so
> my fault entirely.

my wording "matches traffic" was probably part of the confusion ... Could have been formulated better!

> Post 8.3 is a lot more complicated than it used to be :-)

never ever!!! :-)

I prefer the new NAT-syntax in nearly every way.

Jon Marshall · ‎03-03-2015

No problem.

I'm not there yet in terms of preferring the new NAT, seems completely illogical to me once you get to policy NAT/PAT etc.

It's a bit like going from CatOS to IOS on the 6500 if you can remember that far back :-).

Took a while but now I can't imagine doing it any other way !

Jon