Tag Archives: access lists

ASA Access Control Lists Basics Part 2 of 2

This is a follow up to our previous post – please check that one out as we are going to pick up right where we left off.

Screenshot 2015-03-28 08.46.12

Let’s now add an outbound access list on that outside interface and see if we do indeed start to break other types of access through the ASA. We will create one that permits Web traffic outbound:

access-list OUT_OUT permit tcp host 10.10.10.1 host 192.168.1.1 eq www
access-group OUT_OUT out interface outside

Now we just created a bit of a nightmare. Telnet is indeed broken from the inside as it is hitting this access list and getting dropped:

R1#telnet 2.2.2.2
Trying 2.2.2.2 ...
% Connection refused by remote host 
R1#

We can certainly see why it is most common to use inbound access lists on the ASA.

Now Cisco understands that this can all get a bit confusing…inspection, access-lists, access-list direction…so they provide a very powerful tool on the ASA to help you in troubleshooting. The Packet Tracer.

In our previous post – we said that R2 should be able to respond to pings from the inside. We chose to test that by actually going to the device (R1) and initiating the ping. But we could have stayed right on the ASA and confirmed things with Packet Tracer as follows:

ASA1# packet-tracer input outside icmp 192.168.1.1 0 0 10.10.10.1
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.10.10.0      255.255.255.0   inside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUT_IN in interface outside
access-list OUT_IN extended permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply 
...
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
ASA1#

Another powerful tool you can utilize if you are troubleshooting your access lists on the ASA is logging. In our case, the results of our packet tracer above show that the ECHO REPLIES from R2 will be permitted, but of course we have an access list outbound on the outside interface that will actually drop the ECHO packets. In order to see this, I will enable logging and send the results to the console and then try our ping…

ASA1(config)# logging on

ASA1(config)# logging console 7

So now, this is what shows up on the ASA when we try the ping:

%ASA-4-106023: Deny icmp src inside:10.10.10.1 dst outside:192.168.1.1 (type 8, code 0) by access-group "OUT_OUT" [0x0, 0x0]

We love this kind of reporting, letting us know exactly why R1 can no longer ping R2!

I hope you enjoyed this two part series on basic access list usage on the ASA.