SecurityCCNA 200-301

VTY ACL Lockout — All Remote Access Blocked

Presenting Symptom

Remote engineers cannot SSH or Telnet into the router, but local console access works fine.

Network Context

A small branch office with a Cisco 4321 router running IOS XE 16.9. The router has a single VTY line (line vty 0 4) configured for SSH and Telnet. An ACL is applied to the VTY lines to restrict management access to a specific subnet (192.168.1.0/24). After a recent ACL modification, all remote access attempts time out or are rejected.

Diagnostic Steps

Check VTY line configuration

show running-config | section line vty

line vty 0 4
 access-class 10 in
 transport input ssh telnet
 login local

Confirms an access-class is applied. If the ACL number or name is missing, or if transport input is incorrect, that could be the issue.

Inspect the ACL applied to VTY

show access-list 10

Standard IP access list 10
    10 permit 192.168.1.0, wildcard bits 0.0.0.255
    20 deny any

If the ACL does not include the source IP of the remote engineer, or if the order is wrong (e.g., deny before permit), access will be blocked.

Verify remote source IP and test connectivity

show ip interface brief | include Vlan1

Vlan1                    192.168.1.1     YES NVRAM  up                    up

Check the router's interface IP. The remote engineer's source IP must match the ACL permit statement. Also, ping from the remote host to the router to confirm basic IP connectivity.

Check for implicit deny and ACL hits

show access-list 10 | include matches

    10 permit 192.168.1.0, wildcard bits 0.0.0.255 (10 matches)
    20 deny any (5 matches)

If the deny line shows matches, the remote host is being blocked. If the permit line shows no matches, the source IP is not in the permitted range.

Root Cause

The ACL applied to the VTY lines (access-class 10 in) has an incorrect permit statement that does not include the remote engineer's source IP address, or the ACL order is reversed (deny before permit). The implicit deny at the end of the ACL blocks all other traffic.

Resolution

1. Enter global configuration mode: configure terminal 2. Modify ACL 10 to include the correct source subnet or host: ip access-list standard 10 no 10 10 permit 192.168.2.0 0.0.0.255 (or add a new permit statement before the deny) 3. If the ACL order is wrong, remove and re-add entries in correct order. 4. Exit and save: end, write memory

Verification

1. Run 'show access-list 10' to confirm the permit statement includes the remote subnet. 2. From the remote host, attempt SSH: ssh -l admin 192.168.1.1. Should succeed. 3. Check ACL hits: 'show access-list 10' should show matches on the permit line and no new matches on the deny line.

Prevention

1. Always test ACL changes from a console session to avoid lockout. 2. Use a management VLAN and restrict VTY access to a dedicated management subnet. 3. Implement AAA with local fallback and ensure at least one management method (console) is always available.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where a candidate must identify why remote access fails. The exam tests understanding of VTY line configuration, access-class, and standard ACL operation. Key fact: an access-class applied to VTY lines filters incoming connections based on source IP; the implicit deny blocks all other traffic.

Exam Tips

Remember that 'access-class' is used on VTY lines, while 'access-group' is used on interfaces.

The order of ACL entries matters: the first match is applied. A deny any at the top blocks everything.

Use 'show access-lists' to see match counts; if the deny line increments, the source is being blocked.

Commands Used in This Scenario

show running-config

Displays the current active configuration in DRAM, showing all non-default settings.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions