Configuring VTY Lines ACL

Real World Application

In production networks it’s a common security policy to control remote administration to network devices using an access control list specifying only a particular administrative subnets and/or hosts on the network access to establish a remote exec session to the device for management.

This lab will teach you how to configure an ACL to control specific networks and/or host access to establish an exec session via VTY lines used for remote administration.

Lab Prerequisites

Lab Objectives

Lab Instruction

One of the biggest new management features of 12.3T and 12.4 mainline is the ability to use extended access-lists to permit particular traffic to establish an exec session to the vty lines of a Cisco device using a particular protocol; ie, telnet and/or ssh.

Step 1. – Configure a named access-list on R1 called VTY_ACCESS

R1 con0 is now available



Press RETURN to get started.



R1>enable
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip access-list extended VTY_ACCESS
R1(config-ext-nacl)#

Step 2. – Deny host 10.1.1.3 from accessing the vty lines via telnet. In order to complete this objective you’ll need to specify the source as host 10.1.1.3 and destination as any eq telnet as shown below;

R1(config-ext-nacl)#10 deny tcp host 10.1.1.3 any eq telnet

Step 3. – Permit the network range 10.1.1.0/24 to use telnet or ssh. This objective will require two access list entries, one for telnet (tcp port 23) and one for ssh (tcp port 22) as shown below;

R1(config-ext-nacl)#20 permit tcp 10.1.1.0 0.0.0.255 any eq 22
R1(config-ext-nacl)#30 permit tcp 10.1.1.0 0.0.0.255 any eq 23

Step 4. – Deny all other traffic and log the denied connection attempts.

R1(config-ext-nacl)#500 deny ip any any log

Step 5. – Configure the access-list on the vty lines using the access-class command.

R1(config-ext-nacl)#line vty 0 4
R1(config-line)#access-class VTY_ACCESS in
R1(config-line)#end
R1#

Step 6. – Verify your configuration and connectivity using R2 and R3.

Before verifying the connectivity using R2 and R3 first be sure to verify your access-list on R1 using the show ip access-list

R1#show access-list
Extended IP access list VTY_ACCESS
    10 deny tcp host 10.1.1.3 any eq telnet
    20 permit tcp 10.1.1.0 0.0.0.255 any eq 22
    30 permit tcp 10.1.1.0 0.0.0.255 any eq telnet
    500 deny ip any any log
R1#

After verifying the access-list is correct, you can then test connectivity to R1 from R2 using Telnet and/or SSH. Keep in mind when you Telnet or SSH from a Cisco device it will use the IP address of the interface that traffic exits to get to that destination, in this case 10.1.1.2/24 as shown below by the show users command;

R2#telnet 10.1.1.1
Trying 10.1.1.1 ... Open


User Access Verification

Username: tom
Password: 
R1#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:14:12   
*  2 vty 0     tom        idle                 00:00:00 10.1.1.2

  Interface    User               Mode         Idle     Peer Address

R1#exit

[Connection to 10.1.1.1 closed by foreign host]
R2#ssh -l tom 10.1.1.1

Password: 

R1#sh ssh
Connection Version  Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       tom
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       tom
%No SSHv1 server connections running.
R1#

Now using R3 verify that 10.1.1.3/24 is being denied access via telnet and permitted access via SSH to R1 as shown below;

R3#telnet 10.1.1.1
Trying 10.1.1.1 ... 
% Connection refused by remote host

R3#ssh -l tom 10.1.1.1

Password: 

R1#show ssh
Connection Version  Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       tom
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       tom
%No SSHv1 server connections running.
R1#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:13:53   
*  2 vty 0     tom        idle                 00:00:00 10.1.1.3

  Interface    User               Mode         Idle     Peer Address

R1#

You can verify that telnet was indeed denied using the vty line ACL on R1 by executing the show access-list command in privileged mode. This will show you a hit count number beside each access control list entry;

R1#show access-list
Extended IP access list VTY_ACCESS
    10 deny tcp host 10.1.1.3 any eq telnet (1 match)
    20 permit tcp 10.1.1.0 0.0.0.255 any eq 22 (4 matches)
    30 permit tcp 10.1.1.0 0.0.0.255 any eq telnet (6 matches)
    500 deny ip any any log
R1#