Hands-On Lab: Using ACLs to Restrict VTY Access

This hands-on lab configures a standard ACL applied specifically to a router's VTY lines to restrict remote management access to a single trusted management subnet, verifying both permitted and blocked SSH connection attempts.

VTY Access-ClassManagement Plane SecurityRemote Access Restriction

~2 min read · Updated Sep 23, 2026

Lab Objective

Configure a standard ACL and apply it to a router's VTY lines using access-class, restricting SSH access to only a designated management subnet, and verify both an authorized and unauthorized connection attempt.

Lab Purpose

Applying an ACL to a physical interface, as done in earlier labs, controls transit traffic passing through the router. Restricting who can manage the router itself requires a different application point entirely — the VTY lines — which access-class targets specifically.

Lab Topology

R1 (SSH already configured for remote access,
    as covered earlier in this series)

Trusted management subnet: 192.168.99.0/24
Untrusted subnet: 192.168.35.0/24

Task 1: Create a Standard ACL for Management Access

Create numbered ACL 20 permitting only the trusted management subnet.

Task 2: Apply the ACL to the VTY Lines

Apply ACL 20 to all VTY lines using access-class in the inbound direction.

Task 3: Verify Access from the Trusted Subnet

Confirm a management station on 192.168.99.0/24 can successfully SSH into R1.

Task 4: Verify Access Is Blocked from an Untrusted Subnet

Confirm a host on 192.168.35.0/24 cannot SSH into R1.

Solution and Verification

R1(config)# access-list 20 permit 192.168.99.0 0.0.0.255

-- No explicit deny needed, since the implicit
-- deny at the end of every ACL, discussed
-- earlier in this series, already blocks
-- everything not matching this line

R1(config)# line vty 0 15
R1(config-line)# access-class 20 in

ManagementPC (192.168.99.20)> ssh [email protected]

Password:
R1>
-- Successfully connects from the trusted
-- management subnet

UntrustedPC (192.168.35.50)> ssh [email protected]

% Connection refused by remote host
-- The connection attempt is rejected before
-- even reaching the SSH login prompt, since
-- access-class filters at the line level
-- before authentication is ever attempted

R1# show access-lists 20

Standard IP access list 20
    10 permit 192.168.99.0, wildcard bits 0.0.0.255 (3 matches)

Key Takeaway

Unlike ip access-group, which is applied to a physical interface to filter transit traffic, access-class is applied specifically to the VTY lines to control management access to the device itself — this distinction matters because a permissive interface ACL says nothing about who can actually log into the router, and vice versa, so both must be considered as entirely separate security controls.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring OSPF Virtual Links

This hands-on lab connects a disconnected area to the backbone using an OSPF virtual link, addressing a design violation where an area does not have a direct physical connection to Area 0, and verifies routes flow correctly once the virtual link is established.

Continue

Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

Continue

Hands-On Lab: Configuring OSPF Stub and Totally Stubby Areas

This hands-on lab configures a leaf area as a standard stub area, then upgrades it to a totally stubby area, comparing the routing table size at each stage and verifying only a default route remains once fully configured.

Continue

Hands-On Lab: Configuring Multi-Area OSPF with Route Summarization

This hands-on lab configures multi-area OSPF across three routers, designating an ABR that summarizes several subnets from a leaf area into a single route advertised toward the backbone, tying together the area design and summarization concepts covered earlier in this series.

Continue

Hands-On Lab: Configuring EIGRP for IPv6

This hands-on lab configures EIGRP for IPv6 between two routers, activating the protocol directly on each interface similar to OSPFv3's approach, and highlights the mandatory router ID requirement unique to EIGRPv6.

Continue

Hands-On Lab: Configuring OSPFv3 for IPv6

This hands-on lab configures OSPFv3 between two routers to dynamically route IPv6 traffic, comparing its configuration syntax against the OSPFv2 labs covered earlier in this series while highlighting the interface-level activation approach OSPFv3 uses.

Continue