Tag Archives: acls

IPv4 Access Lists in the CCIE Lab Exam

CCIE Coaching, CCIE R&S, , , ,

Security

I am getting ready for my Nugget on the above subject and I wanted to provide some thoughts and notes here on the blog on this important subject.

I am currently training for a half-marathon. Yes, and thanks for putting up with all of my RunKeeper Tweets on the subject. 🙂 With the training, there are certain metrics you need to hit in order to really determine if you can finish on race day. It is the same way the CCIE. One metric is ACLs. If you do not have them mastered, you are in big trouble on race day. Think about it, you use them for traffic filtering, and then traffic identification for a whole host of features on the devices. QoS, network management, the list goes on and on.

The traffic filtering part gets really scary. Drop one in that is not doctored up for the other traffic required in your lab scenario and you can easily break things well enough to fail. And when you are building the lists, you must really take your time to ensure that you are meeting their specific directions. Are you getting the EXACT traffic they want, in the correct direction?

Here is a list of tips and things to think about for this important topic. These are in no particular order:

  • Read so carefully if you need to build an ACL traffic filter. Often, you will be asked to block something extremely specific, for example, echo-replies. Should you block too generally, like requests and replies, you fail the task.
  • Drawing out the scenario on your scratch paper will often help you with what specifically to match and in what direction.
  • You certainly would want to avoid this in production, but in the lab it is fine to end your ACLs with deny ip any any log-input. This will allow you to see just what you broke in your lab with your ACL!
  • Remember that an outbound ACL will not impact traffic generated by that local router.
  • access-group is used for traffic filtering on your interfaces, while access-class is used for your VTY lines. Remember with the access-class out command, it is controlling where someone can Telnet out of your router AFTER they have already Telnetted into it.

ASA Access Control List Basics Part 1 of 2

CCIE Security, , , , , ,

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.