Community ForumCommunity Wiki * Blog Home  * Log in
« »

Lock-and-Key Security (Or how I learned to love the Dynamic ACL)

posted in Cisco Networking, Technical
by on April 4th, 2011 tags: , , , ,

I’ll be honest. I have no idea where you would ever use this feature. But yet Dynamic ACLs exist and Lock-and-Key security is a tool that a Cisco network administrator has at his or her disposal. As such, I’m now going to blog about this because I need to make sure I know them in case they show up on my CCIE lab attempt and perhaps you might find this at least interesting if not actually useful.

So what is Lock-and-Key security? Well the short version is that Lock-and-Key security allows for an ACL to have dynamic entries that become active under certain conditions thereby allowing or disallowing network traffic to flow in a predetermined manner.

An Example

Let’s use this simple topology to illustrate the idea.

The task is to telnet from R2 to R3, but R1 has an ACL inbound on E0/1 that does not permit telnet through to R3. We must first “unlock” R1 and then we can telnet to R3. For this task we’re going to assume full reachability and we only care about the loopbacks of X.X.X.X where X is the router number for each device.

Let’s jump right in and look at this ACL first, then we’ll step backwards and look at how we make all this work.

OK…looks a little weird, but nothing too bad. If we look at each line individually we see line 10 is our dynamic line, line 20 allows telnet access to the local loopback (we need this later), line 30 denies all other telnet from passing, and then line 40 permits everything else. For right now just know that line 10 is not active. If we try and telnet from R1 to R3 it will not work.

Great… So how do we make this all work? The secret sauce is in the EXEC mode command “access-enable” and the “autocommand” feature.

The idea with Lock-and-Key is that you use a specially configured login on a router to activate the dynamic ACL entry which is turn allows you to access resources behind that router. We can configure this login in a couple of different ways.

For this example I’m going to use the second method.

So, now we’re all set. We first telnet to R3 to prove it doesn’t work. We then telnet to R1 and login with our special ID (the router will immediately drop the session) to activate the dynamic ACE. Finally, we telnet to R3 and go about whatever it is we need to do on R3.

Yay! Success!

What does R1′s ACL look like now?

Once the access-enable command is run the router adds in the dynamic line (the unnumbered line) to the ACL and start processing it as it would any other ACE. In this case, it start allowing us to telnet to and gain access to R3.

Keep in mind this ACE is not added to the starup-config and is not saved to NVRAM. This ACE is present in the running-config only and will be lost after a reboot.

There’s a couple other things you can do here, and I’m only going to quickly talk about them. The first is that you can have the dynamic ACE created be specific to the host that “unlocked” the router by adding the “host” keyword to the “access-enable” command (either on the username command or on the VTY line).

The second is that you can optionally configure a timeout value for the dynamically added ACEs. This is done either within the dynamic ACE itself (absolute timeout) or on the “access-enable” command (idle timeout).

If you don’t configure a timeout using one of the two methods then the dynamic entry will remain present until it is manually cleared using the “clear access-template” EXEC command.

And that’s about it for Lock-and-Key.


Here is the full Cisco doc for this feature on


A thread has been created on the site forum specifically for commenting on this blog post.