Solved: Query regarding Cisco ASA ACLs

Mahi Gurram · ‎10-18-2013

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:

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

Jouni Forss · ‎10-18-2013

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

View solution in original post

Mariusz Bochen · ‎10-18-2013

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

View solution in original post

Jouni Forss · ‎10-21-2013

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

View solution in original post

Jouni Forss · ‎10-22-2013

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

View solution in original post

Jouni Forss · ‎10-18-2013

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

Mariusz Bochen · ‎10-18-2013

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

Mahi Gurram · ‎10-21-2013

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

Jouni Forss · ‎10-21-2013

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

Mahi Gurram · ‎10-21-2013

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

Jouni Forss · ‎10-22-2013

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

Mahi Gurram · ‎10-24-2013

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:

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.
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)
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