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 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه