A coworker recently came to me for help with an issue. We have a server sitting behind a router at one of our remote sites. Certain people need RDP access to this server, but we do not want it open to the world, this seems like an ideal scenario for Lock and Key access lists. Lock and Key ACLs are a way to permit temporary access to a resource. Static ACLs either allow or deny, they can create temporary openings to suit a specific need. In our example it will be a telnet server behind a router. Here’s the topology:

Here we see a host on one side of R1 (Fa0/0) and a server on the other side (Fa1/0). In this example we want very limited access to Telnet on that server. Here’s our config:

interface FastEthernet0/0
 description To Host
 ip address
 ip access-group Telnet in
interface FastEthernet1/0
 description To Server
 ip address
ip access-list extended Telnet
 dynamic allow_telnet permit tcp any host eq telnet
 deny   tcp any host eq telnet
 permit ip any any
username allow password 0 allow
username allow autocommand access-enable host timeout 10

We have our interfaces configured, Fa0/0 connects to the host and Fa1/0 connects to the server. Our ACL is blocking Telnet to the server and permitting everything else. The dynamic line in the ACL is the one that matters. This will dynamically allow Telnet to the server when the command “access-enable” is run. We have the username “allow” running the “access-enable host timeout 10″ command, this opens up the ACL to allow Telnet to the server for 10 minutes, after 10 minutes it will timeout and the user will need to log in again. The “host” entry in the ACL makes it so only the IP used with the username allow is permitted, if “host” is left off the ACL will allow any source to connect via Telnet to the server. Let’s see it in action:

Trying ...
% Destination unreachable; gateway or host down
Trying ... Open
Username: allow
[Connection to closed by foreign host]
Trying ... Open

We see that Telnet is definitely blocked, then we connect to R1 with the “allow” username. After that we try again and see that Telnet works fine. Let’s look at the ACL on R1:

R2#sh ip access-listExtended IP access list Telnet
    10 Dynamic allow_telnet permit tcp any host eq telnet log
       permit tcp host host eq telnet (12 matches) (time left 381)
    20 deny tcp any host eq telnet (3 matches)
    30 permit ip any any (222 matches)

We see that new line added allowing Telnet access from (our host) to (our server). It also shows us how long until the entry times out.

That’s it! We have a secure Telnet server behind our router, it is only accessible if the correct user is authenticated on R1. I hope someone finds this useful.


Colby Glass has been in IT since 2002. He is currently a Systems Engineer (presales) with a Cisco Gold partner and holds the CCNP R/S, CCNP DC, CCDP, CCIP, JNCIA-ER.

More Posts