ACLCCNA 200-301

ACL on VTY Lines Locking Out Admin Access

Presenting Symptom

An administrator is unable to SSH or Telnet into a Cisco router from a remote management workstation, even though the IP connectivity is verified.

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 access. The management workstation is on a different subnet (192.168.2.0/24) and can ping the router's management IP (192.168.1.1/24). The router is configured with an access-list that was intended to permit only specific management hosts.

Diagnostic Steps

1

Check VTY line configuration

show running-config | section line vty
line vty 0 4
 access-class 10 in
 transport input ssh telnet
 login local

The 'access-class 10 in' command applies an ACL to incoming VTY connections. If the ACL is misconfigured, it can block all traffic.

2

Examine the applied ACL

show access-lists 10
Standard IP access list 10
    10 deny   any (2 matches)

The ACL shows only a deny any entry, meaning all traffic is blocked. The matches counter indicates packets have been denied.

3

Verify management workstation IP

show ip interface brief | include 192.168.1.1
GigabitEthernet0/0/0    192.168.1.1       YES manual up                    up

Confirms the router's management interface is up and has the correct IP address.

4

Test connectivity from workstation

ping 192.168.1.1 source 192.168.2.100
Success rate is 100 percent (5/5)

Ping succeeds, so Layer 3 connectivity is fine. The issue is specifically with VTY access, pointing to the access-class ACL.

Root Cause

The access-class 10 applied to VTY lines uses a standard ACL that only contains a 'deny any' entry, blocking all inbound SSH/Telnet sessions. This was likely a misconfiguration where the administrator forgot to add permit statements for the management hosts.

Resolution

1. Enter global configuration mode: configure terminal 2. Modify ACL 10 to permit the management subnet: access-list 10 permit 192.168.2.0 0.0.0.255 3. (Optional) Remove the deny any if not needed: no access-list 10 deny any 4. Exit and save: end, write memory

Verification

Run 'show access-lists 10' to confirm the permit entry is present and matches increase. Then attempt SSH from the management workstation: ssh -l admin 192.168.1.1. Expected: successful login.

Prevention

1. Always include a permit statement for the management subnet before the deny any in the ACL. 2. Use a more specific ACL that only permits required hosts. 3. Test ACL changes from a console session to avoid locking yourself out.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where a candidate must identify why remote management is failing. The exam tests understanding of 'access-class' command and standard ACLs. Key fact: 'access-class' filters incoming VTY connections using a standard ACL.

Exam Tips

1.

Remember that 'access-class' applies to VTY lines, while 'access-group' applies to interfaces.

2.

Standard ACLs should be placed as close to the destination as possible; for VTY lines, the ACL checks the source IP.

3.

When troubleshooting remote access, always check 'show access-lists' for match counters to see if traffic is being permitted or denied.

Commands Used in This Scenario

Test Your CCNA Knowledge

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

Practice CCNA Questions