ASA Security Level traffic flow question

[ty.masse]

I'm having a strange issue with an ASA configuration.  I'm configuring a guest network which allows them to go to the internet, but not have access to anything on the inside or dmz interface.  I also have the dhcp relay configuration to allow the guest devices to get an IP address from our main dhcp server located on the inside.  Below is the security level of my interfaces:

outside 0

guest 5

dmz 50

inside 100

By default I was expect the implicit rule in the ASA to allow higher security to lower security.  Which in this case would allow the guest devices to go to the internet with no access to the dmz or inside. 

When configured in this way they had no internet access at all.  They did get an IP address.  Which told me that the relay config is working.

To get it to work I had to create an ACL and allowed internet traffic.  But it also allows backflow traffic all the way to the inside interface.  I had to put deny statement in the ACL to prevent that.

My question is why is it not working implicitly?  I shouldn't need an ACL at all.  Please assist me with this issue.

Thanks for your assistance.

[Marvin Rhoads]

You're right - an access list should not be required.

Try removing it and then running the ASA packet-tracer command to see where the problem lies. i.e.:

packet-tracer input guest tcp <guest ip address> 1025 8.8.8.8 80

[ty.masse]

Thanks for your reply.  When I did that it works.  However I forgot one part in my description.  The clients need to make a connection to the inside to get to a captive portal page on port 80.  That's the real reason why we have the ACL.

1. Why would it work backwards to the higher security interface with ACL only and no NAT?  I'm puzzled by that.

2. How can I get it to work by allowing  access to the captive portal device only?

[ty.masse]

This is the message I was expecting to get when initiating traffic from security 5 to 100.  This is a packet trace I did from google to the outside interface.

ASA(config)# packet-tracer input outside tcp 8.8.8.8 80 x.x.x.x 1025

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in   x.x.x.x    255.255.255.0   outside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop  
Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate

ASA(config)# 

[Vibhor Amrodia]

Hi,

Can you provide your NAT configuration on the ASA device.

Thanks and Regards,

Vibhor Amrodia
 

[ty.masse]

I found this link below and based on that it seems that Cisco has changed things to where if the traffic is to a directly connected network and you have an ACL it will allow the traffic in any direction no matter the security level.  That's not the way it used to be.

The old rule was higher security to lower security required NAT. It can only communicate to the lower security via the NAT address.   Lower security to higher security required ACL.  That way a mistake in the ACL would not expose the more secure side to a security breach since there is not NAT.   However with the new rule if there is a mistake in the ACL, the lower security for example the DMZ can initiate traffic to any directly connected network on the ASA.

I used to work on a 8.2 ASA if we had a public web server we natted it to a public address and allowed port 80 on the outside ACL.  If that server needed access to a databases server on the inside, we would expose the inside interface to the dmz by natting it to itself and allow access in the DMZ ACL.  I was shocked yesterday that the ACL allowed the guest traffic to anything on the inside network. I don't agree with that design but can live with it.  It's something I didn't know before.

Am I correct in my understanding on how the new ASA is supposed to work?

https://supportforums.cisco.com/discussion/11924711/cisco-asa-security-level-and-explicit-deny-acl

Thanks.

[Marvin Rhoads · Accepted solution]

The requirement to use NAT (nat-control) is deprecated as of ASA 8.3.

In the absence of an ACL, higher security level is allowed to initiate traffic to lower security levels. Once any ACL is applied to an interface, that takes precedence (with an implicit "deny any any" as the final entry in the access list).

Lower security level may only initiate traffic to a higher security level if is allowed by an ACL.

[ty.masse]

I guess I didn't realize that before.  I don't know how Cisco thinks that  makes the ASA more secure.  While it makes it easier, I don't think it's an improvement in security.

Nothing I can do about it.

Thanks everyone for your responses.

[Marvin Rhoads]

Please re-run packet tracer initiating from guest with an outside destination as I posted earlier.

Introducing packets into the data path from outside to a private internal IP address would not be expected to work (as noted by the ASA in the output you provided).

[Rejohn Cuares]

Post your ASA config and don't forget to remove sensitive information.