Cisco ASA Access-List

Hi Georgi,

Sure this can be done with object groups:

Rene

hi renee ; thanks for the respond for object group .I have another question from this access list example above you mention.in the global access list example be love ;
ASA1(config)# access-list SMTP extended permit tcp host 192.168.3.3 eq 25 any
I couldn’t get this access list statement since you put the "any " after specifying the port number .can you please explain it for me ?
thanks

Hi Georgi,

In the extended access-list you can match things like this:

So in that example, we use:

protocol = tcp
source ip = 192.168.3.3
source port = 25
destination ip = any
port = any

Rene

Hi Rene,
I am confused about the section “Permit Traffic to DMZ”

How were you able to telnet the interface on the DMZ router,192.168.3.3, from the outside, R2? I think you should telnet the NATTED IP instead.

Thanks

Hi John,

I had a default route on R2 pointing to the ASA.

Rene

Hi Rene,

I have that too, R2 points to the ASA, but the lab did not work for me. I think it is a static NAT issue because the ASA drops the packet due to rpf-check. Here is a packet tracer from the ASA

ciscoasa# packet-tracer input OUTSIDE tcp 192.168.2.2 23 192.168.3.3 23

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

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.3.0     255.255.255.0   DMZ

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE_INBOUND in interface OUTSIDE
access-list OUTSIDE_INBOUND extended permit tcp any host 192.168.3.3 eq telnet 
Additional Information:

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

Phase: 5
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network WEB_SERVER
 nat (DMZ,OUTSIDE) static 192.168.2.200
Additional Information:

Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Hi John,

That makes sense :slight_smile: In my example I didn’t have NAT configured…just the IP addresses and security levels on the ASA, that’s it.

Rene

perfect, thank you!!

Hi Rene !

Dont you need nat , when you are using accesslist all security level will diminish ? or am i wrong ?

Hi Oskar,

If this was a real network with Internet connectivity and public/private addresses then yes, you would need NAT. In this example however it’s just an ASA with three interfaces. Nothing has to be translated.

Rene

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