Cisco ASA Access-List

Hi Rene,

What’s the order on a given INT -Is this ACL evaluated first and then NAT is applied.

ASA1(config)# access-group OUTSIDE_INBOUND in interface OUTSIDE– Referencing to this line what operation is performed first NAT OR ACL and

if it is NAT then this change the source IP to given public IP and overriding the ACL condition which defines what host/subnet to be permitted or denied source IP.

-Thanks in advance

Hi Asi,

Here’s a good document from Cisco that explains the “order of operation” for the ASA:

Cisco ASA Packet Flow

The packet tracer tool on the ASA is also great to answer this question. For example:

ASA# packet-tracer input INSIDE tcp 192.168.1.1 50001 1.2.3.4 80

This will show us the packet flow for a host that is using IP address 192.168.1.1 and who wants to connect to TCP port 80 on 1.2.3.4. Here’s the result:

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:
found next-hop 10.10.10.1 using egress ifc  OUTSIDE

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
object network INSIDE
 nat (INSIDE,OUTSIDE) dynamic interface
Additional Information:
Dynamic translate 192.168.1.1/50001 to 10.10.10.254/50001

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: SFR
Subtype: 
Result: ALLOW
Config:
class-map SFR
 match access-list SFR_REDIRECT
policy-map global_policy
 class SFR
  sfr fail-open
service-policy global_policy global
Additional Information:

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:       
Additional Information:
New flow created with id 1017213, packet dispatched to next module

You can see that the access-list is checked BEFORE NAT is applied. If your packet doesn’t match the access-list then it will be dropped before NAT translation occurs.

Hope this helps.

Rene

Hi Rene,

I have a basic question as am just getting to know about ASA firewalls. Doesn’t Standard and named access-lists work on ASA? I haven’t been able to see that configuration.

Thank you,
BV

Hello Bharathi!

If you’re familiar with access lists on a Cisco router IOS then most of what you know can be transferred to the ASA. However, there are some differences that you have to keep in mind:

  1. The ASA uses subnet masks instead of wildcard masks used on a router
  2. ACLs on the ASA are named instead of numbered
  3. ACLs on the ASA are assumed to be extended

Otherwise, for the most part, they are configured in the same manner as on a router. Use the Cisco context sensitive help (using the ? in the CLI) to help you out concerning the syntax of the commands. Try it out, as actually configuring ACLs, as with all CLI commands, helps the most in learning the proper method of applying commands.

I hope this helps!

Laz

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