Cisco ASA Access-List

Hi Rene,

Awesome lab.

Quick question I come from cisco IOS routing and switching background and had a question about the ACL Processing, how does it process the ACLs in terms of do i need to enter a permit ip any any at the end of each ACL Name?

Thanks.

Hi Rene,

In this lab i noticed after each ACL you created an ip any any why not just create one at the very end.?

Hi Sina,

ACL processing works pretty much the same as on Cisco IOS. In these examples I added some specific permit and deny statements, which is why I added a permit ip any any at the bottom to accept everything else.

Rene

19 posts were merged into an existing topic: Cisco ASA Access-List

Hi Rene,

one question regarding the “Restrict Outbound Traffic” scenario.

If the ASA would NAT here and we would work with src ip in the ACL statement, we would have to specify the NAT IP address in the SRC part, right?
As the packet is routed and NAT´d first before the ACL is applied, right? If we go from “inside” to “outside”.

Thanks
Florian

Hi Rene,

a question regarding those statements:

•When you create an ACL statement for inbound traffic (lower to higher security level) then the destination IP address has to be: ◦The translated address for any ASA version before 8.3.
◦The real address for ASA 8.3 and newer.

•The access-list is always checked before NAT translation.

If the ACL is checked first, does the dest IP not have to be the NAT´d IP then?
Cause the ASA looks at the packet and compares it to the ACL. In the packet we still have the NAT´d IP and therefore we would need to specify the NAT´d IP in the ACL, or not?
Cause otherwise the ACL wouldn’t match the packet!?

Thanks
Florian

Hello Florian

As Rene mentioned at the beginning of the lesson:

When you create an ACL statement for outbound traffic (higher to lower security level) then the source IP address is the real address of the host or network (not the NAT translated one).

This means that when applying an ACL for trafficf going from INSIDE to OUTSIDE, the real IP address is used, that is the actual IP address of the internal host and NOT the NAT’d address.

So this means that we would work with the REAL address of the source.

I hope this has been helpful!

Laz

Hello Florian

According to Cisco:

Although the syntax of the ACLs haven’t changed much (just added capabilities for new objects), the significant change is that all IP addresses listed in ACLs which are applied to an interface will be converted (on upgrade) from using global (ie: translated or post-NAT) IP addresses, to using the real IP address.

This means that in all cases the real address must be used for post ASA 8.3 versions.

The comment that:

The access-list is always checked before NAT translation

is the case for all ACLs that function with NAT EXCEPT for the case of ACL statement for inbound traffic.

I hope this has been helpful!

Laz

Hi Laz,

thanks again for your reply.

So this means in either case we will always use the REAL IP address for the ACL statement.
As you mentioned before that we will always use the REAL IP address for post 8.3. versions and that for INBOUND traffic NAT is performed first and thus we will need the REAL IP address in the ACL statement.
Is that correct?

But my first question was regarding the “Restrict Outbound Traffic” scenario.
Here the ACL was placed on the on the OUTSIDE interface outbound and thats why I thought that you would need to use the NAT´d IP address in the ACL statement as the traffic will hit the ingress interface INSIDE, then will be NAT´d and then will hit the OUTSIDE interface with the ACL attached to it, which means the IP has changed already.
I think I didn’t make myself clear before, hope its better now.

Thanks for your help in advance!
Florian

Hello florian

In the restrict outbound traffic scenario, the IP address that is used to match the access list is the 192.168.2.2 address. This is the FastEthernet 0/0 interface of R2. This is an external IP address and does not actually get translated at all. The ALL_OUTBOUND access list only matches destination IP addresses for packets going from the INSIDE or DMZ ports to the OUTSIDE port. Again, this destination address will not be translated therefore the criteria for which the matching takes place does not change.

I’m not sure if I’ve misunderstood your question or if I’ve answered it satisfactorily. Please let me know and if you need any clarifications, feel free to respond.

I hope this has been helpful!

Laz

Hi Laz,

let me give you a short example of what I mean:

Client1--------192.168.1.0/24------------------(inside)ASA(outside)-------------------172.16.1.0/24

If we have the scenario described above and the ASA does NAT from inside to outside and on the outside interface there is an outbound ACL applied to it. The NAT IP address is 172.16.1.10.
The ACL statement would be: access-list INSIDE_Outside deny tcp host 172.16.1.10 host 192.168.2.2 eq 80

I mean I would use here the NAT IP in the ACL statement as the packet coming from Client1 will hit the ASA and the source IP is NAT´d first before the ACL on the outbound interface is hit, correct?

Thanks for your help!

Florian

Hello Florian.

in the scenario that you are describing, you are correct, that would be the case.

I hope this has been helpful!

Laz

Thanks a lot for your help Laz!!

1 Like

Hi I’m really confused bt this statement “The access-list is always checked before NAT translation”

So if I have traffic coming into the asa on the outside interface with a public IP address destined for a server on my dmz who has a private IP address translated by nat to the outside public address would I permit traffic destined from anywhere as an example to the private ip address of my server NOT the NAT public address?

Thanks

Simon

Hello Simon

Generally, the order of operations for incoming and outgoing packets can be seen in this document:


Having said that, when we say that the access list is always checked before NAT, it means that source and destination addresses of the packet will be examined and matched BEFORE the translation occurs.

So let’s say you have a web server on your DMZ with an IP address of 10.10.10.10 and a NAT translation rule that translates this IP address to an external address of 72.10.10.10. A host with an IP address of 2.25.25.25 on the internet sends a packet to your web server. The packet will have a source address of 2.25.25.25 and a destination address of 72.10.10.10.

Now which particular IP addresses you will be filtering depend on your access list, which interface it is applied on and in which direction. For example:

If you want to filter this traffic with an INCOMING access list on the OUTSIDE interface, you will have to filter based on public source and destination IP addresses, because the access list will act on the packet BEFORE any addresses are translated.

If you want to filter this traffic with an OUTGOING access list on the DMZ interface, you will have to filter based on public source addresses and private destination addresses. This is because at this point, the NAT translation has already taken place on the incoming interface, and the destination IP address in the packet will be the translated address of 10.10.10.10. Note that for such incoming traffic, the source address of 2.25.25.25 is not translated. Only the destination address, that of the web server is.

I hope this has been helpful!

Laz

Thanks for taking the time to reply Laz very much appreciated

Simon

1 Like

Can we block https traffic on ASA.

Hello Mohammed

One way to block HTTPS traffic on a Cisco ASA device, or even on an IOS router, would be to simply use access lists and filter any traffic using TCP port 443 which is used by HTTPS. You can find more information about how to implement that in this lesson.

This of course is not foolproof, since users and servers can change the port being used by HTTPS and bypass the access lists. The only other way to do this is to use deep packet inspection. However, as this Cisco documentation states:

HTTPS filtering is not supported on ASA. ASA cannot do deep packet inspection or inspection based on regular expression for HTTPS traffic, because in HTTPS, content of packet is encrypted (SSL).

I hope this has been helpful!

Laz

Hi ,

In a scenario I have an access-list “ALL_INBOUND” applied IN on INSIDE interface.
Here I have deny 192.168.1.2 and rest is permitted.

access-list ALL_INBOUND deny any host 192.168.1.2
access-list ALL_INBOUND permit any any 

access-group ALL_INBOUND in interface INSIDE.

Further I also created a global access-list and applied on global
Here I have deny 192.168.2.1,192.168.3.1 & rest is permitted.

access-list Global-acl  extended deny ip any host 192.168.2.1
access-list Gloabl-acl  extended deny ip any host 192.168.3.1

access-group Gloabl-acl global

In this scenario if 192.168.2.1 try to enter IN. Will the global-acl trigger and drop the traffic
Or as INSIDE interface has (access-list ALL_INBOUND permit any any ) mentioned 192.168.2.1 will be allowed under this.

Hello Syed

Global access lists will apply to all interfaces in an inbound direction. In your interface ACL, you are denying any traffic that is incoming on the INSIDE interface that has a destination IP of 192.168.2.1.

You state here that the “rest is permitted” but you don’t have a permit any any statement at the end of your Gloabl-acl access list. I assume that is a typo.

In this scenario, if you have an incoming packet to the INSIDE interface with a destination IP of 192.168.2.1, it will be dropped. Actually, both access lists (interface and global) deny it, but the interface access list will always take precedence over a global access list. So in this scenario, it is the ALL_INBOUND access list that blocks the packet.

I hope this has been helpful!

Laz