ASA interfaces, no ACL applied inbound or outbound

wilson_1234_2 · ‎05-12-2016

I am working with an ASA setup that I have not seen before.

ASA5585-SSP-10

Software Version 9.1(7)4 <context>
Device Manager Version 7.1(1)52

There are multiple contexts, but at the moment, those are not related to the question I have.

Each context has multiple interfaces, but for the most part, there are no ACLs applied.

The outside Interface has one applied on the inbound direction, but the inside interface doesn't have one applied at all.

Routes are configured to direct traffic.

there is a dynamic NAT configured:

nat (INSIDE,OUTSIDE) after-auto source dynamic INTERNAL interface

My question is how the ASA handles traffic, if no ACLs are applied to specify what is allowed and denied.

I am thinking that the ASA will allow all traffic by default from a higher security level to a lower one, but if no ACL is applied from lower to higher, all of that traffic is blocked.

So, with no ACL applied to the inside interface (security level 100), any traffic sourced from inside is allowed through, and from outside to inside, the ACL will specify what is allowed.

Any other interface that has no ACL applied, allows no traffic to a lower lever interface.

Is this correct?

Karsten Iwen · ‎05-12-2016

I am thinking that the ASA will allow all traffic by default from a higher security level to a lower one, but if no ACL is applied from lower to higher, all of that traffic is blocked.

correct! But to be more specific, all new connections are blocked. All return traffic is automatically allowed by the statefull inspection.

So, with no ACL applied to the inside interface (security level 100), any traffic sourced from inside is allowed through, and from outside to inside, the ACL will specify what is allowed.

correct as long as the traffic is routed to an interface with a lower security level (there could be other interfaces with 100)

Any other interface that has no ACL applied, allows no traffic to a lower lever interface.

No, it's a general rule that traffic is allowed to lower level interface regardless if it's inside, DMZ or whatever.

wilson_1234_2 · ‎05-12-2016

Thanks for the reply,

This "Any other interface that has no ACL applied, allows no traffic to a lower lever interface."

Should have been "Any other interface that has no ACL applied, allows no traffic to a higher level interface."

I would like to understand this better:

"correct! But to be more specific, all new connections are blocked. All return traffic is automatically allowed by the statefull inspection."

So, say I have two interfaces with no ACL applied to either, Inside(100) and DMZ1(50).

If I source ICMP traffic to a device in the DMZ, I should expect to see that traffic hit the device in the DMZ, but unable to return that traffic back to Inside.

Or are you saying that even without an ACL applied to either interface, I should expect to see the return traffic?

And, if I am not seeing the return traffic, should I look at NAT being an issue?

My understanding was with the newer images, (8.3 or 8.4 or later), NAT was not needed across the ASA interfaces by default.

Karsten Iwen · ‎05-12-2016

NAT is not needed any more. And if there is no NAT-rule, the traffic is forwarded without translation. Well, only if allowed by ACL or security-level.

For ICMP you have to be aware that this is not statefully inspected by default. This has to be enabled in the policy-map.

For your example, lets assume we have:

no inspection for ICMP and no ACLs

The ICMP echo-request is allowed by sec-level to the DMZ-host, but no entry is added to the state-table.
The answer packet reaches the lower security-level interface and is dropped.

no ACLs but ICMP-inspection enabled

The ICMP echo-request is allowed by sec-level to the DMZ-host, and the ASA adds an entry to the state-table.
The echo reply matches this state-entry and is allowed.

3) no ACL on inside and an ACL "permit icmp any any echo-reply" on the DMZ, no icmp-inspection

1. The ICMP echo-request is allowed by sec-level to the DMZ-host, but no entry is added to the state-table.
2. The echo-reply can't be matched against an entry in the state table and is compared against the ACL. There the echo-request is allowed.

wilson_1234_2 · ‎05-12-2016

Thanks for the great information.

I may have some more questions for you, but in the meantime, have you ever set up a firewall this way, or ever seen it done?

It was a CCIE that configured this, but it seems that with no ACLs applied, you lose a huge element of control over traffic.

The way you have explained it, since I do have ICMP inspection enabled, this would explain why I am not getting that traffic returned, but IP traffic, TCP, UDP traffic is not getting inspected, so anything sourced from higher interface is going to get returned (if I am getting all the points).

Karsten Iwen · ‎05-12-2016

I prefer to have ACLs on all interfaces for full control of the traffic.

For the inspection: The ASA inspects TCP and UDP by default, so this traffic should work. For ICMP, do you have a typo in your last statement? With ICMP enabled, you should get the replies back.

wilson_1234_2 · ‎05-12-2016

Ok, I needed to re-read your earlier post.

I do have inspection enabled, so I should get the reply back, but I am not.

So, I guess I need to look into why I am not:

policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect ip-options
inspect netbios
inspect rsh
inspect sqlnet
inspect sunrpc
inspect tftp
inspect xdmcp
inspect pptp
inspect icmp
inspect icmp error
!
service-policy global_policy global

Karsten Iwen · ‎05-12-2016

That means taht ICMP is inspected and you should be able to ping through the ASA. Can you again describe exactly what's not working?

wilson_1234_2 · ‎05-12-2016

I believe it is working as expected.

There are a lot of VRFs on the core switch and I believe I was testing from a VRF that doesn't have a route to the network in the DMZ when I tried before.

I tried from the cores switch, from the VRF of the inside interface, and was a ble to ping across the interfaces.

I appreciate your help in understanding this.

I may have some more questions regarding the context mode these ASAs are currently in.

Karsten Iwen · ‎05-12-2016

> I believe it is working as expected.

fine!

> I may have some more questions regarding the context mode these ASAs are currently in.

I think starting a new thread for this is a good idea.