Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Query regarding Cisco ASA ACLs

Hello All,

I just started learning Cisco ASA firewall and i got stuck up while understanding  Cisco  ASA's ACL configurations and  your insight and help in this regard is  highly appreciated.

Refer the below image to understand my query better:

CiscoASA_ACL.jpg

My Networks Details:

Network behind LAN Interface - 172.16.0.1/255.255.0.0

Network behind DMZ1 Interface - 192.168.50.1/255.255.255.0

Network behind DMZ2 Interface - 192.168.1.1/255.255.255.224

Scenario 1:

Now i want to write an ACL (ACL_INSIDE) for the input traffic of LAN Interface. Hence i'm planning to configure my access-group as below:

access-group ACL_INSIDE in interface LAN

My problem is, i couldn't understand, what that input traffic to LAN interface refers to?

Is it Traffic A (as mentioned in the above image - On LAN Interface) or Traffic B (as mentioned in the above image - On LAN Interface)  or both?

Say Traffic A alone refers to input traffic of LAN interface: (Refer the below scenario and correct me if i'm wrong)

In this case, in all of my ACL_INSIDE ACEs, SRC IP should always be the Original IP of my LAN Network and DST IP could be of anything.

Also can i use the public IP of my LAN interface as a SRC IP in ACL??

Sample ACL: (LAN Network -> 172.16.0.1/255.255.0.0)

Valid ACLs:

    access-list acl_inside permit tcp host 172.16.0.24 192.168.50.25 eq ftp

Invalid ACLs:

      access-list acl_inside permit udp any host 172.16.0.4 eq ntp

     access-list acl_inside permit udp any host 62.16.0.4** eq ntp
** 62.16.0.4 is the public IP of 172.16.0.4

Say Traffic B alone refers to input traffic of LAN interface: (Refer the below scenario and correct me if i'm wrong)

In this case, in  all of my ACL_INSIDE ACEs, DST IP should always be the Original  IP/Public IP of my LAN Network and SRC IP could be of anything.

Sample ACL: (LAN Network -> 172.16.0.1/255.255.0.0)

Valid ACLs:

     access-list acl_inside permit udp any host 172.16.0.4 eq ntp

     access-list acl_inside permit udp any host 62.16.0.4** eq ntp

**62.16.0.4 is the public IP of 172.16.0.4

Invalid ACLs:

     access-list acl_inside permit tcp host 172.16.0.24 192.168.50.25 eq ftp

Say Traffic A and Traffic B both refers to input traffic of LAN interface: (Refer the below scenario and correct me if i'm wrong)

In this case, I can use my LAN network as either SRC IP or DST IP of an ACL.

Sample ACL:(LAN Network -> 172.16.0.1/255.255.0.0)

Valid ACLs:

     access-list acl_inside permit tcp host 172.16.0.24 192.168.50.25 eq ftp

     access-list acl_inside permit udp any host 172.16.0.4 eq ntp

     access-list acl_inside permit udp any host 62.16.0.4** eq ntp
**62.16.0.4 is the public IP of 172.16.0.4

Scenario 2:

Say i want to write an ACL (ACL_INSIDE) for the output traffic of LAN Interface. Hence i need to configure my access-group as below:

access-group ACL_INSIDE out interface LAN

Just let me know that i should consider this case is exactly opposite  to the above scenario or is there any special cases that i need to  understand?

Your help on this is highly appreciated.

Awating your response,

Thanks in Advance,

Best Regards,

Mahi

  • Firewalling
4 ACCEPTED SOLUTIONS

Accepted Solutions
Super Bronze

Query regarding Cisco ASA ACLs

Hi,

Essentially the direction "in" or "out" is related to the interface itself.

The direction "in" in the "access-group" command refers that you are controlling traffic incoming from behind that interfaces towards that interface.

The direction "out" in the "access-group" command refers that you are controlling traffic that is heading out through that interface towards the networks located behind that interface.

I would suggest sticking to using only "in" (Inbound) ACLs on your interfaces since its the natural choice to control the traffic in the interface closest to the source host.

If you configure both "in" and "out" ACLs for the same interface you might end up creating a needlesly complex ACL configuration that will cause headache in the future.

Notice the fact also that when you have allowed something in a "in" ACL on an interface, you wont have to allow return traffic at another interface where the reply is coming from.

Scenario 1.

The ACL configured with "access-group ACL_INSIDE in interface LAN" controls traffic that is entering from behind the interface LAN

Scenario 2.

The ACL configured with "access-group ACL_INSIDE out interface LAN" controls traffic that is heading to the networks behind interface LAN. Essentially it means the traffic has already crossed some other interface on the ASA (possibly controlled by some inbound ACL) and now goes through the LAN interface and goes through the "out" direction check before the traffic is allowed to reach the networks behind interface LAN.

The above is the reason why I basically just use "in" direction ACLs on the interface. Its the simplest way and using also an "out" direction ACL just means the same traffic is checked twice againts ACLs.

There are some situations to use both "in" and "out" ACLs but to be honest there have been very few situations for me personally.

Hope this helps

- Jouni

New Member

Query regarding Cisco ASA ACLs

Hi Mahi,

You have to imagine that you are inside the firewall, and then everything will start to make sense.

IN means everything going through an interface will be filtered. So if you have Network behind LAN Interface - 172.16.0.1/255.255.0.0, with access-group ACL_INSIDE in interface LAN,  first example is correct (access-list acl_inside permit tcp host 172.16.0.24 192.168.50.25 eq ftp). You're basically going to filter everything coming FROM the specified network to any different interface.

Same when you have outside interface with something like ACL_OUTSIDE in interface outside. In this example you're going to filter traffic coming from outside (eg. Internet) to your local network.

access-group ACL_INSIDE out interface LAN is not really recommended as it's more efficient to filter traffic before enter the firewall, not after. However in some scenarios can become useful (if we have to filter traffic from many different subinterfaces to one destination). Personally I've never seen that configured in my life

I hope that helps.

Regards

Mariusz

Super Bronze

Re: Query regarding Cisco ASA ACLs

Hi,

First of regarding the Static NAT configuration you mentioned

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0 

This essentially does the following

  • When connection is formed from "inside" to "DMZ2" the source address of 172.16.0.9 is NATed to the IP address 192.168.1.4
  • When connection is formed from "DMZ2" to "inside" to the destination IP address 192.168.1.4 then that destination address is UN-NATed from 192.168.1.4 to 172.16.0.9

With regards to Question 1.

The source address "any" simply says that any source address behind "DMZ2" can connect to the destination IP address 192.168.1.4. The reason why you would need such an ACL rule (ACE) for allow traffic to a destination IP address in the connected network is because you have Static NATed a host behind "inside" towards the "DMZ2" to an IP address belonging to "DMZ2" connected network. (Look at the above explanation of the Static NAT when traffic is going to 192.168.1.4 from behind "DMZ2")

With regards to Question 2.

If you need a NAT configuration for the destination IP address depends on your situation. Usually this is not neede between local LAN/DMZ interfaces. Atleast I myself will usually leave out all NAT configurations between local interfaces. Usually you need a Static NAT between internal and external interfaces. For example when configuring Static NAT for one of your servers so it can be reached from the Internet.

An important thing to notice related to this matter is that the NAT behaviour in different ASA software levels is considerably different. You are using some version 8.2 (or below) while NAT/ACL format in 8.3 (or above) is completely different in logic and the above information doesnt apply to it anymore)

With regards to Question 3.

We wont be able to tell your for what traffic this UDP "any" rule is configured for. The most likely would be UDP/53 (DNS) among others like UDP/123 (NTP). You can either monitor logs or capture UDP traffic on the firewall to determine what UDP traffic is coming. You can also check the hitcount of the ACL with "show access-list" command to determine if its getting any hits.

Hope this helps

Please do remember to mark replys as correct answers if they answered your question and/or rate helpfull answers.

Feel free to ask more if needed though

- Jouni

Super Bronze

Query regarding Cisco ASA ACLs

Hi,

The "ACL_INSIDE" statement doesnt make much sense if there is no corresponding NAT configuration NATing some other address towads the "inside" interface to the NAT IP address of 172.16.0.6.

You could naturally check the output of

show access-list ACL_INSIDE

And check if this rule even has any hitcounts. But to me it seems like a useless rule if there is no corresponding Static NAT configuration for the IP address 172.16.0.6. The reason is that the traffic inside the same subnet should not use the default gateway (ASA) for any traffic. That traffic should flow between the actual hosts since they are in the same subnet (they would use ARP to determine to which MAC address the traffic is sent)

If you want to see what ASA NAT configurations and ACL rules some certain traffic would match on the ASA then the "packet-tracer" command is great.

Take for example the Static NAT between "inside" and "DMZ2"

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0

You have a ACL rule that allows SMTP traffic towards this server

  access-list ACL_DMZ2 permit tcp any host 192.168.1.4 eq smtp

So if you wanted to simulate a packet incoming from host 192.168.1.100 towards IP address 192.168.1.4 with destination port TCP/25 (SMTP) then you could use this command

packet-tracer input DMZ2 tcp 192.168.1.100 12345 192.168.1.4 25

The output of this command would tell you what rules the ASA would apply to such a packet. You might end up with a short output if the traffic/packet would actually be blocked by some configuration.

The general format of the "packet-tracer" command should be pretty easy to understand

  • You first enter "packet-tracer input"
  • You then follow that with a source interface behind which the packet would be coming from and you would have "packet-tracer input DMZ2"
  • You would then choose the protocol (TCP/UDP/ICMP) which would end up with "packet-tracer input DMZ2 tcp"
  • You then choose th source IP address which can be any random address from the source network usually and you would have "packet-tracer input DMZ2 tcp 192.168.1.100"
  • You then choose the source port for the simulated packet/connection which could also be random and you would end up with "packet-tracer input DMZ2 tcp 192.168.1.100 12345"
  • You then add the destination IP address for the packet. It could be a NAT IP address if NAT is done for the destination IP as it is in this case. Then you would end up with "packet-tracer input DMZ2 tcp 192.168.1.100 12345 192.168.1.4"
  • Finally you add the destination port for the packet/connection and you end up with the full format of the command which is "packet-tracer input DMZ2 tcp 192.168.1.100 12345 192.168.1.4 25"

Hope this helps

With regards to the ratings. If you have already marked an answer as the correct answer then you have given that answer the full rating of 5 Stars. If you feel that some answer wasnt the exact correct answer but wish to rate it then you would first hower your mouse pointer over the gray stars below the reply and when the mouse pointer is over the amount of stars you want to give as rating you would click to choose that amount (it cant be changed later)

- Jouni

7 REPLIES
Super Bronze

Query regarding Cisco ASA ACLs

Hi,

Essentially the direction "in" or "out" is related to the interface itself.

The direction "in" in the "access-group" command refers that you are controlling traffic incoming from behind that interfaces towards that interface.

The direction "out" in the "access-group" command refers that you are controlling traffic that is heading out through that interface towards the networks located behind that interface.

I would suggest sticking to using only "in" (Inbound) ACLs on your interfaces since its the natural choice to control the traffic in the interface closest to the source host.

If you configure both "in" and "out" ACLs for the same interface you might end up creating a needlesly complex ACL configuration that will cause headache in the future.

Notice the fact also that when you have allowed something in a "in" ACL on an interface, you wont have to allow return traffic at another interface where the reply is coming from.

Scenario 1.

The ACL configured with "access-group ACL_INSIDE in interface LAN" controls traffic that is entering from behind the interface LAN

Scenario 2.

The ACL configured with "access-group ACL_INSIDE out interface LAN" controls traffic that is heading to the networks behind interface LAN. Essentially it means the traffic has already crossed some other interface on the ASA (possibly controlled by some inbound ACL) and now goes through the LAN interface and goes through the "out" direction check before the traffic is allowed to reach the networks behind interface LAN.

The above is the reason why I basically just use "in" direction ACLs on the interface. Its the simplest way and using also an "out" direction ACL just means the same traffic is checked twice againts ACLs.

There are some situations to use both "in" and "out" ACLs but to be honest there have been very few situations for me personally.

Hope this helps

- Jouni

New Member

Query regarding Cisco ASA ACLs

Hi Mahi,

You have to imagine that you are inside the firewall, and then everything will start to make sense.

IN means everything going through an interface will be filtered. So if you have Network behind LAN Interface - 172.16.0.1/255.255.0.0, with access-group ACL_INSIDE in interface LAN,  first example is correct (access-list acl_inside permit tcp host 172.16.0.24 192.168.50.25 eq ftp). You're basically going to filter everything coming FROM the specified network to any different interface.

Same when you have outside interface with something like ACL_OUTSIDE in interface outside. In this example you're going to filter traffic coming from outside (eg. Internet) to your local network.

access-group ACL_INSIDE out interface LAN is not really recommended as it's more efficient to filter traffic before enter the firewall, not after. However in some scenarios can become useful (if we have to filter traffic from many different subinterfaces to one destination). Personally I've never seen that configured in my life

I hope that helps.

Regards

Mariusz

New Member

Re: Query regarding Cisco ASA ACLs

Hi All,

First of all i want to thank JouniForss and Mariusz Bochen for responding to my post.

Now i got  it clear what "IN" and "OUT" in access-group refers to. But i have some  sample Cisco Configurations with me, in which few ACLs are conflicting  with your explanation and hence it is confusing me. Could you please  help me in understanding those things also.

My Networks Details:

Network behind LAN Interface - 172.16.0.1/255.255.0.0

Network behind DMZ1 Interface - 192.168.50.1/255.255.255.0

Network behind DMZ2 Interface - 192.168.1.1/255.255.255.224

Also (if needed) you can refer to the image which i have pasted in my original post.

NAT related query:

Say below is my Static NAT Configuration:

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0

What the above Static NAT rule says is 'while traffic goes from inside -> DMZ2, the IP address 172.16.0.19 of LAN network will be NATed to 192.168.1.4'.

Is this NAT rule also mean 'while traffic goes from DMZ2 -> inside , IP address 192.168.1.4 will be NATed to 172.16.0.19?'

Access-List related query:

Before understanding my query related to ACLs, refer the static NAT configurations (that are used in the ACLs), access-group,ACL configurations(taken from my sample ASA configuration) mentioned below:

Part of NAT Configurations (taken from my sample config):

static (DMZ2,outside) 62.59.14.163 192.168.1.2 netmask 255.255.255.255 0 0

static (DMZ2,outside) 62.59.14.200 192.168.1.200 netmask 255.255.255.255 0 0

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0

Part of access-group configurations (taken from my sample config):

access-group ACL_DMZ2 in interface DMZ2

ACL_DMZ2 ACL Configurations (taken from my sample config):

access-list ACL_DMZ2 permit tcp any host 192.168.1.4 eq smtp

access-list ACL_DMZ2 permit tcp any host 192.168.1.2 eq smtp

access-list ACL_DMZ2 permit tcp any host 192.168.1.2 eq pop3

access-list ACL_DMZ2 permit udp host 192.168.1.2 any eq domain

access-list ACL_DMZ2 deny tcp any host 192.168.1.2 object-group mail_svcs

access-list ACL_DMZ2 permit tcp host 192.168.1.200 host 172.16.1.200 118

access-list ACL_DMZ2 permit udp host 192.168.1.200 host 172.16.1.200 eq 118

As per my understanding, ACL "IN" on an interface (based on your explanation), refers to the traffic that is originating from the network behind that interface and to the any other interface. i.e; Always the SRC IP in the ACE is IP related to the network behind that interface and the DST IP could be anything. Now below are my queries:

Question 1:

But if you observe the first ACE of the above mentioned quotted box (access-list ACL_DMZ2 permit tcp any host 192.168.1.4 eq smtp) which is applied on DMZ2 interface (192.168.1.1/255.255.255.224) on input traffic, the SRC IP is Any and the DST IP is the DMZ2 network IP. How should i interpret this?

Because as per your explanation, always the SRC IP Should be the network behind that interface. But here, network behind that interface is in DST IP of an ACE which is conflicting. Please clarify.

Question 2:


In this case (i.e; ACL is applied on "IN"), always do we need to apply NAT  for DST IP of an ACL to determine the DST Interface of the ACL. Or do we  have any other way to determine to which interface that ACE is destined  to?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Apart from this, the below two ACEs that are applied on "IN" Traffic of LAN Interface are also confusing me.

access-list ACL_INSIDE permit udp host 192.168.5.251 any

access-list ACL_INSIDE udp any host 172.16.0.6 eq ntp

Question 3:

In the first among the above two, SRC IP is 192.168.5.251 (not related to LAN Network but routed to LAN Gateway) and DST IP is Any. and Service is not mentioned at all...What service should i consider?

and the 2nd ACE of above two, is same as my question 2 that will answer to this.

Once again i thank you all for assisting me in this regard. Its so nice of you to share the knowledge.

Best Regards,

Mahi

Super Bronze

Re: Query regarding Cisco ASA ACLs

Hi,

First of regarding the Static NAT configuration you mentioned

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0 

This essentially does the following

  • When connection is formed from "inside" to "DMZ2" the source address of 172.16.0.9 is NATed to the IP address 192.168.1.4
  • When connection is formed from "DMZ2" to "inside" to the destination IP address 192.168.1.4 then that destination address is UN-NATed from 192.168.1.4 to 172.16.0.9

With regards to Question 1.

The source address "any" simply says that any source address behind "DMZ2" can connect to the destination IP address 192.168.1.4. The reason why you would need such an ACL rule (ACE) for allow traffic to a destination IP address in the connected network is because you have Static NATed a host behind "inside" towards the "DMZ2" to an IP address belonging to "DMZ2" connected network. (Look at the above explanation of the Static NAT when traffic is going to 192.168.1.4 from behind "DMZ2")

With regards to Question 2.

If you need a NAT configuration for the destination IP address depends on your situation. Usually this is not neede between local LAN/DMZ interfaces. Atleast I myself will usually leave out all NAT configurations between local interfaces. Usually you need a Static NAT between internal and external interfaces. For example when configuring Static NAT for one of your servers so it can be reached from the Internet.

An important thing to notice related to this matter is that the NAT behaviour in different ASA software levels is considerably different. You are using some version 8.2 (or below) while NAT/ACL format in 8.3 (or above) is completely different in logic and the above information doesnt apply to it anymore)

With regards to Question 3.

We wont be able to tell your for what traffic this UDP "any" rule is configured for. The most likely would be UDP/53 (DNS) among others like UDP/123 (NTP). You can either monitor logs or capture UDP traffic on the firewall to determine what UDP traffic is coming. You can also check the hitcount of the ACL with "show access-list" command to determine if its getting any hits.

Hope this helps

Please do remember to mark replys as correct answers if they answered your question and/or rate helpfull answers.

Feel free to ask more if needed though

- Jouni

New Member

Re: Query regarding Cisco ASA ACLs

Hi,

Once again i thank you so much for clarifying all my doubts. Now i can able to understand the ACL and NAT configurations of ASA 8.2 version with all your help.

This is so nice of you to share the knowledge to the people like me.

I got one more small doubt, could you please clarify that one also.

Before  understanding my query related to ACLs, refer the static NAT  configurations (that are used in the ACLs), access-group,ACL  configurations(taken from my sample ASA configuration) mentioned below:

My Networks Details:

Network behind LAN Interface - 172.16.0.1/255.255.0.0

Network behind DMZ1 Interface - 192.168.50.1/255.255.255.0

Network behind DMZ2 Interface - 192.168.1.1/255.255.255.224

Part of NAT Configurations (taken from my sample config):

static (DMZ2,outside) 62.59.14.163 192.168.1.2 netmask 255.255.255.255 0 0

static (DMZ2,outside) 62.59.14.200 192.168.1.200 netmask 255.255.255.255 0 0

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0

Part of access-group configurations (taken from my sample config):

access-group ACL_DMZ2 in interface DMZ2 
access-group ACL_INSIDE in interface LAN 

Part of ACL Configurations (taken from my sample config):

access-list ACL_DMZ2 permit tcp any host 192.168.1.4 eq smtp

access-list ACL_INSIDE permit udp any host 172.16.0.6 eq ntp

**In the above ACL configuration samples, as they are applied to input  traffic of their respective interfaces, always the SRC IP should be  related to the network behind that interface (I mean network associated  with that interface) and the DST IP could be any other IP related to  some other interface.

If you observe the first ACE (ACL_DMZ2) of above sample, the SRC IP is Any and the DST IP is 192.168.1.4 and as per your earlier explanation, that ACE refers to permit smtp traffic from and 'Any' IP with in DMZ2 to 172.16.0.19 (NATed IP of 192.168.1.4) and it makes sense.

And if you observe the second ACE (ACL_INSIDE) of above sample, the SRC IP is Any and the DST IP is 172.16.0.6.

Now how should i interpret/understand this ACE? Because there is no NAT rules configured to  translate 172.16.0.6 IP. 

As per my understanding (based on your earlier  explanations) always SRC IP of an ACL is related to the network behind  that interface and the DST IP could be any other IP related to some  other interface. But here it is contradicting. So please help me in  understanding this ACE.

Once again i really appreciate for all your help to me till now in understanding the ACL concepts.

Take a bow Cisco Forums.

** I have marked the replies as correct but i couldn't understand where to give rating to the answers.

Thanks Again.

Awaiting your response,

Best Regards,

Mahi


Super Bronze

Query regarding Cisco ASA ACLs

Hi,

The "ACL_INSIDE" statement doesnt make much sense if there is no corresponding NAT configuration NATing some other address towads the "inside" interface to the NAT IP address of 172.16.0.6.

You could naturally check the output of

show access-list ACL_INSIDE

And check if this rule even has any hitcounts. But to me it seems like a useless rule if there is no corresponding Static NAT configuration for the IP address 172.16.0.6. The reason is that the traffic inside the same subnet should not use the default gateway (ASA) for any traffic. That traffic should flow between the actual hosts since they are in the same subnet (they would use ARP to determine to which MAC address the traffic is sent)

If you want to see what ASA NAT configurations and ACL rules some certain traffic would match on the ASA then the "packet-tracer" command is great.

Take for example the Static NAT between "inside" and "DMZ2"

static (inside,DMZ2) 192.168.1.4 172.16.0.19 netmask 255.255.255.255 0 0

You have a ACL rule that allows SMTP traffic towards this server

  access-list ACL_DMZ2 permit tcp any host 192.168.1.4 eq smtp

So if you wanted to simulate a packet incoming from host 192.168.1.100 towards IP address 192.168.1.4 with destination port TCP/25 (SMTP) then you could use this command

packet-tracer input DMZ2 tcp 192.168.1.100 12345 192.168.1.4 25

The output of this command would tell you what rules the ASA would apply to such a packet. You might end up with a short output if the traffic/packet would actually be blocked by some configuration.

The general format of the "packet-tracer" command should be pretty easy to understand

  • You first enter "packet-tracer input"
  • You then follow that with a source interface behind which the packet would be coming from and you would have "packet-tracer input DMZ2"
  • You would then choose the protocol (TCP/UDP/ICMP) which would end up with "packet-tracer input DMZ2 tcp"
  • You then choose th source IP address which can be any random address from the source network usually and you would have "packet-tracer input DMZ2 tcp 192.168.1.100"
  • You then choose the source port for the simulated packet/connection which could also be random and you would end up with "packet-tracer input DMZ2 tcp 192.168.1.100 12345"
  • You then add the destination IP address for the packet. It could be a NAT IP address if NAT is done for the destination IP as it is in this case. Then you would end up with "packet-tracer input DMZ2 tcp 192.168.1.100 12345 192.168.1.4"
  • Finally you add the destination port for the packet/connection and you end up with the full format of the command which is "packet-tracer input DMZ2 tcp 192.168.1.100 12345 192.168.1.4 25"

Hope this helps

With regards to the ratings. If you have already marked an answer as the correct answer then you have given that answer the full rating of 5 Stars. If you feel that some answer wasnt the exact correct answer but wish to rate it then you would first hower your mouse pointer over the gray stars below the reply and when the mouse pointer is over the amount of stars you want to give as rating you would click to choose that amount (it cant be changed later)

- Jouni

New Member

Re: Query regarding Cisco ASA ACLs

Hi,

Thank you so much JounisForss for your detailed explanation on NAT and ACL Configurations. Now i understood completely.

I started learning these concepts for 8.3 version and above and i found below are the differences w.r.t NAT and ACLs from Pre 8.3 and 8.3 and above versions:

        1. The NAT Configurations are completely different from all previous version of ASA. https://supportforums.cisco.com/docs/DOC-9129
          document will explain this in detail.
        2. The IP addresses used in the ACLs are different (pre-8.3 versions used the global/translated IPs, whereas 8.3 always uses the real IPs (untranslated)
        3. A new concept of host-based objects was introduced, to allow singular hosts to be referenced by their names (previously, we had the name command, but that was more of a macro-substitution in the show running-config output).

      I found that there are no differences in these NAT and ACL configurations from versions 8.3 to 9.1. Please let me know if there are any.

      Apart from this, i have few doubts in understanding AAA Rules. Could you please clarify me.

      Refer the below AAA,ACL configurations to understand my query better. (Consider the AD/RADIUS/etc...configurations that are needed for identity rules are already done.)

      My ACL Configuration:

      hostname(config)# access-list 100 extended permit tcp any 192.168.50.118 255.255.255.255 eq http
      hostname(config)# access-list 100 ex permit ip user CISCO\xyz any any
      hostname(config)# access-list 100 ex deny ip user CISCO\abc any any
      hostname(config)# access-list 100 ex permit ip user NONE any any

      hostname(config)# access-list 100 ex deny any any

      hostname(config)# access-list 200 ex permit user NONE any any

      My access-group Configuration:

      hostname(config)# access-group 100 in interface inside 

      My HTTP Access Configuration:

      hostname(config)# http server enable

      hostname(config)# http 0.0.0.0 0.0.0.0 inside
      hostname(config)# 
      hostname(config)# auth-prompt prompt Enter Your Authentication 
      hostname(config)# auth-prompt accept You are Good 
      hostname(config)# auth-prompt reject Goodbye
      My AAA Server Configuration:
      hostname(config)# aaa-server LDAP protocol ldap - AAA Server NAME (LDAP)
       
      hostname(config-aaa-server-group)# aaa-server LDAP (inside) host 171.1.2.93 - AAA Server Host(172.1.2.93)
      hostname(config-aaa-server-host)#  ldap-base-dn DC=cisco,DC=com
      hostname(config-aaa-server-host)#  ldap-group-base-dn DC=cisco,DC=co
      hostname(config-aaa-server-host)#  ldap-scope subtree
      hostname(config-aaa-server-host)#  ldap-login-dn cn=kao,OU=Employees,OU=Cisco  Users,DC=cisco,DC=com
      hostname(config-aaa-server-host)#  ldap-login-password *****
      hostname(config-aaa-server-host)#  ldap-over-ssl enable
      hostname(config-aaa-server-host)#  server-type microsoft
      Case 1:
      hostname(config)# aaa authenticate match 200 inside LDAP
      
      
      Case 2:
      hostname(config)# aaa authenticate match 200 inside user-identity 
      Case 3:
      hostname(config)# aaa authenticate match 200 inside LDAP user-identity  

      Now how should i understand the above ACLs i.e; 100 and 200 in all the above three cases/types of AAA match configurations.(especially the ACLs that have user as NONE - bolded one).

      Please help me in understanding this.

      You have always been a great help to me & I salute for that.

      Awaiting your response,

      Best Regards,

      -Mahi

      318
      Views
      0
      Helpful
      7
      Replies
      This widget could not be displayed.