Tag Archives: firewall

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.

ASA Access Control List Basics Part 1 of 2

In this post – we are going to create a quick ASA topology in GNS3 and have some fun with access lists basics.

Here is our topology – I will go ahead and configure OSPF everywhere so we have full reachability. I also placed X.X.X.X loopbacks on the devices that will be nice for testing purposes. I used 3.3.3.3 on the TestPC:

Screenshot 2015-03-28 08.46.12If you are wondering what those hubs are all about – I read somewhere that they are the least finicky when it comes to getting the ASA to speak to the devices on the network. I know direct connections and the Ethernet Switch in GNS3 are both buggy. I cannot wait for VIRL to feature the ASA in April 2015.

So we better start with a basic sanity check. Lets try and Telnet from the inside (R1) to the outside (R2). We expect this to work of course thanks to the inspection of TCP and UDP traffic by the ASA with its default rules in place:

R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open
User Access Verification
Password:
R2>

Well – that worked great – did the ASA inspect it? Let’s check:

ASA1# show conn detail
7 in use, 10 most used
...
TCP outside:2.2.2.2/23 inside:10.10.10.1/64631,
flags UIO, idle 57s, uptime 59s, timeout 1h0m, bytes 102
ASA1#

Yes indeed.

Now – let’s say we want R1 to be able to ping R2. This is not possible by default. Let’s punch a hole in the outside interface inbound so that ECHO-REPLY packets can make it for this specific ping.

access-list OUT_IN permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply
access-group OUT_IN in interface outside

So I just did the ping on R1 (ping 192.168.1.1) and it worked perfectly, so that very specific access list did its job.

But wait a minute – didn’t we just break Telnet from the inside to the outside? That access list has an implicit deny all at the end…

I just tried a Telnet from R1 to R2 and it worked perfectly just as before. What gives?

Well – for those Reply packets for the Telnet from the inside, inspection happens first – then the ACL. So the traffic is indeed permitted in this case even with our outside access control list permitting the ping responses.

DO NOT CONFUSE ACCESS LISTS WITH INSPECTION. They are indeed two different things and it is very important to know each separately and how they operate – and then how they would react when combined.

Thanks for reading. We will take this topology and have even more fun with it in the next post.