Applying ACLs to Interfaces

1. Why Apply ACLs to Interfaces?

Creating an ACL is only the first step — an ACL has no effect whatsoever until it is applied to an interface in a specific direction. Applying an Access Control List (ACL) to an interface is what activates it, causing the router or switch to evaluate every packet passing through that interface against the ACL's rules.

ACLs applied to interfaces serve several critical network functions:

Security enforcement: Block unauthorised traffic from reaching sensitive servers or subnets.
Traffic filtering: Permit only specific protocols, ports, or source/destination combinations.
Policy compliance: Enforce business rules — e.g., prevent HR from accessing IT infrastructure.
Edge protection: Filter inbound traffic at WAN interfaces to block spoofed or malicious packets.
VTY access control: Restrict which hosts can SSH or Telnet to the router's management plane.

Critical rule: Only one ACL per protocol, per direction, per interface can be applied. For example, one IPv4 ACL inbound and one IPv4 ACL outbound on the same interface — never two inbound ACLs on the same interface simultaneously.

2. Inbound vs. Outbound ACLs

The direction in which an ACL is applied is defined from the router's perspective, not the network's perspective. Inbound and outbound are always relative to the interface being configured.

Direction	When Applied	Router Action	Typical Use Case
Inbound (`in`)	Packet arrives on the interface	ACL evaluated before routing decision — denied packets never reach the routing table	Block traffic from untrusted sources at the edge; most efficient — drops unwanted traffic immediately
Outbound (`out`)	Packet is about to leave the interface	ACL evaluated after routing decision — packet has already been routed, now filtered at egress	Restrict what internal users can send out; filter traffic after routing selects the exit interface

Packet Processing Flow — Inbound vs. Outbound

  INBOUND ACL (applied on Gi0/0):
  ┌─────────────────────────────────────────────────────────────┐
  │  External Host                                              │
  │       │                                                     │
  │       ▼                                                     │
  │  [Gi0/0 — Inbound ACL evaluated HERE]                      │
  │       │                                                     │
  │  Permit? → Routing table lookup → Forward to destination   │
  │  Deny?  → Packet dropped, never reaches routing engine     │
  └─────────────────────────────────────────────────────────────┘

  OUTBOUND ACL (applied on Gi0/1):
  ┌─────────────────────────────────────────────────────────────┐
  │  Internal Host                                              │
  │       │                                                     │
  │       ▼                                                     │
  │  [Gi0/0 — Packet arrives, routing lookup performed]        │
  │       │                                                     │
  │  Routing selects Gi0/1 as exit interface                   │
  │       │                                                     │
  │  [Gi0/1 — Outbound ACL evaluated HERE]                     │
  │       │                                                     │
  │  Permit? → Packet forwarded out Gi0/1                      │
  │  Deny?  → Packet dropped at egress                         │
  └─────────────────────────────────────────────────────────────┘

Efficiency tip: Inbound ACLs are more efficient than outbound ACLs for blocking traffic — they drop packets before the router wastes resources on routing lookups. Use inbound ACLs on external-facing interfaces to filter attack traffic early.

3. Interface Types Where ACLs Can Be Applied

Interface Type	Example	Common ACL Use
Physical Ethernet	`GigabitEthernet0/0`, `FastEthernet0/1`	Edge filtering, inter-VLAN policy, WAN access control
Serial / WAN	`Serial0/0/0`	Filter traffic on WAN links — block spoofed source addresses
SVI (Switch Virtual Interface)	`interface Vlan10`	Inter-VLAN traffic filtering on Layer 3 switches
Loopback	`interface Loopback0`	Protect management plane traffic reaching the router
Tunnel	`interface Tunnel0`	Filter traffic on GRE or IPsec tunnel interfaces
VTY Lines (management)	`line vty 0 4`	Restrict which hosts can SSH/Telnet to the device (uses `access-class` not `access-group`)

VTY ACLs use a different command: For restricting Telnet/SSH access to VTY lines, use access-class (not ip access-group) under line vty configuration. See Section 7 below.

4. The ip access-group Command — Syntax and Usage

The ip access-group command, entered in interface configuration mode, is what binds an ACL to an interface in a specific direction.

Command Syntax

Router(config)# interface <interface-id>
Router(config-if)# ip access-group {access-list-number | access-list-name} {in | out}

Applying a Numbered Standard ACL Inbound

! Create ACL: deny host 192.168.1.100, permit everything else
Router(config)# access-list 10 deny host 192.168.1.100
Router(config)# access-list 10 permit any

! Apply ACL 10 inbound on GigabitEthernet0/0
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group 10 in

Applying a Numbered Extended ACL Outbound

! Create ACL: block Telnet (TCP 23) from 10.1.1.0/24, permit all other IP
Router(config)# access-list 101 deny tcp 10.1.1.0 0.0.0.255 any eq 23
Router(config)# access-list 101 permit ip any any

! Apply ACL 101 outbound on GigabitEthernet0/1
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group 101 out

Applying a Named ACL

! Create named extended ACL
Router(config)# ip access-list extended BLOCK_TELNET
Router(config-ext-nacl)# deny tcp 10.1.1.0 0.0.0.255 any eq 23
Router(config-ext-nacl)# permit ip any any

! Apply named ACL outbound on GigabitEthernet0/1
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group BLOCK_TELNET out

Applying Both Inbound and Outbound on the Same Interface

! Different ACLs in each direction on the same interface
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group 10 in          ! Standard ACL inbound
Router(config-if)# ip access-group BLOCK_TELNET out ! Named ACL outbound

Both directions at once: You can apply one ACL inbound and a different ACL outbound on the same interface. What you cannot do is apply two ACLs in the same direction on the same interface — the second application overwrites the first without warning.

5. ACL Placement Rules — Standard vs. Extended

Where you place an ACL on the network is just as important as its configuration. The placement rule differs between standard and extended ACLs due to what each type can match.

Standard ACL — Place Close to the Destination

Standard ACLs (numbered 1–99, 1300–1999) filter based on source IP address only. They cannot distinguish traffic by destination, protocol, or port. If placed close to the source, a standard ACL would block that source from reaching all destinations — not just the intended one. Placing it close to the destination limits the impact to only the relevant traffic.

  PC-A (10.1.1.10) ─── Router A ─── Router B ─── Server (10.3.3.10)
                              ↑
                    Standard ACL placed here (close to destination Server)
                    → Blocks PC-A from reaching only Server, not others
                    
  If placed on Router A's outbound (close to source):
  → PC-A blocked from reaching EVERYTHING beyond Router A (too broad!)

Extended ACL — Place Close to the Source

Extended ACLs (numbered 100–199, 2000–2699) filter on source IP, destination IP, protocol, and port. Because they can precisely identify the target traffic, placing them close to the source prevents that traffic from traversing the network at all — saving bandwidth and router resources.

  PC-A (10.1.1.10) ─── Router A ─── Router B ─── Server (10.3.3.10)
         ↑
  Extended ACL placed here (close to source PC-A)
  → Blocks PC-A's Telnet to Server specifically, before it consumes WAN bandwidth
  → All other PC-A traffic (HTTP, DNS, etc.) still flows normally

Placement Summary

ACL Type	Matches On	Recommended Placement	Reason
Standard (1–99)	Source IP only	Close to destination	Avoids blocking the source from all other destinations unintentionally
Extended (100–199)	Src IP, Dst IP, Protocol, Port	Close to source	Drops specific unwanted traffic immediately, saving network bandwidth
Named Standard	Source IP only	Close to destination	Same logic as numbered standard ACLs
Named Extended	Src IP, Dst IP, Protocol, Port	Close to source	Same logic as numbered extended ACLs

6. The Implicit Deny and Its Impact

Every ACL in Cisco IOS ends with an invisible implicit deny all statement — equivalent to deny ip any any. This is never shown in the configuration but is always evaluated last. Any packet that does not match any explicit ACE (Access Control Entry) is silently dropped.

Common trap: An engineer creates an ACL to block one host and applies it inbound:

access-list 10 deny host 192.168.1.100
! No permit statement added!

interface GigabitEthernet0/0
 ip access-group 10 in

Result: Host 192.168.1.100 is blocked as intended — but all other hosts are also blocked by the implicit deny. The fix is to add access-list 10 permit any after the deny statement.

! Correct — explicit permit after the deny
access-list 10 deny host 192.168.1.100
access-list 10 permit any               ! Without this, ALL traffic is blocked

interface GigabitEthernet0/0
 ip access-group 10 in

Exam tip: The implicit deny is one of the most frequently tested ACL concepts on CCNA. Always ask: "Does this ACL have a permit statement that allows legitimate traffic through?" If the ACL only contains deny statements, it blocks everything.

7. Applying ACLs to VTY Lines (Management Access Control)

VTY lines control Telnet and SSH access to the router itself. Applying an ACL to VTY lines restricts which hosts can remotely manage the device. This uses access-class (not ip access-group) under line vty configuration.

! Create a standard ACL permitting only the management subnet
Router(config)# access-list 5 permit 10.10.10.0 0.0.0.255
! Implicit deny blocks all other SSH/Telnet attempts

! Apply to VTY lines
Router(config)# line vty 0 4
Router(config-line)# access-class 5 in
Router(config-line)# transport input ssh
Router(config-line)# login local

Effect: Only hosts in the 10.10.10.0/24 management subnet can SSH to this router. All other SSH or Telnet attempts are silently refused by the implicit deny at the end of ACL 5. The access-class command applies the ACL to the logical VTY line — it controls who can open a session, not which packets traverse a network interface.

See: SSH Configuration | Console & VTY Line Configuration

8. Real-World Scenario — Full ACL Application Walkthrough

Scenario: A company network has three subnets:
— Finance: 10.10.10.0/24 → VLAN 10
— HR: 10.20.20.0/24 → VLAN 20
— Servers: 10.30.30.0/24 → VLAN 30

Requirements:
1. Finance can access the server subnet (any service).
2. HR cannot access the server subnet at all.
3. No one can Telnet (TCP 23) to any host.
4. Only the management subnet (10.99.99.0/24) can SSH to the router.

Implementation

! ── Requirement 1 & 2: Finance allowed to servers, HR blocked ────────────
! Extended ACL — place close to source (HR VLAN SVI)
Router(config)# ip access-list extended VLAN20-POLICY
Router(config-ext-nacl)# deny ip 10.20.20.0 0.0.0.255 10.30.30.0 0.0.0.255
Router(config-ext-nacl)# permit ip any any

Router(config)# interface Vlan20
Router(config-if)# ip access-group VLAN20-POLICY in

! ── Requirement 3: Block Telnet to any host ──────────────────────────────
! Extended ACL outbound on WAN interface (close to source of Telnet)
Router(config)# ip access-list extended BLOCK-TELNET-OUT
Router(config-ext-nacl)# deny tcp any any eq 23
Router(config-ext-nacl)# permit ip any any

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group BLOCK-TELNET-OUT out

! ── Requirement 4: Restrict SSH to management subnet ─────────────────────
Router(config)# access-list 99 permit 10.99.99.0 0.0.0.255
Router(config)# line vty 0 4
Router(config-line)# access-class 99 in
Router(config-line)# transport input ssh

9. Verifying ACL Application

After applying an ACL, always verify it is active, applied to the correct interface and direction, and matching traffic as expected.

Key Verification Commands

Command	What It Shows	When to Use
`show ip interface Gi0/0`	Which ACL is applied inbound and outbound on a specific interface	Confirm ACL is applied to the correct interface and direction
`show ip interface brief`	Interface status — does not show ACLs but confirms interface is up	Pre-check before ACL troubleshooting
`show access-lists`	All ACLs and their ACEs with hit counters (matches per rule)	Check if rules are being matched and which traffic is hitting each entry
`show ip access-lists`	IPv4 ACLs only with hit counters	Confirm IPv4 ACL entries and match counts
`show running-config \| include access`	All ACL-related lines in the running config including interface applications	Quick overview of all ACL definitions and interface bindings
`show running-config interface Gi0/0`	Full config for a specific interface including any applied ACLs	Confirm ACL application on a specific interface without scrolling

Sample show ip interface Output

Router# show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 192.168.1.1/24
  Inbound  access list is 10          ← ACL 10 applied inbound
  Outbound access list is BLOCK_TELNET ← Named ACL applied outbound

Sample show access-lists Output with Hit Counters

Router# show access-lists
Standard IP access list 10
    10 deny   host 192.168.1.100 (38 matches)   ← 38 packets matched this deny
    20 permit any (1024 matches)                 ← All other traffic permitted

Extended IP access list BLOCK_TELNET
    10 deny tcp 10.1.1.0 0.0.0.255 any eq telnet (5 matches)
    20 permit ip any any (2891 matches)

Hit counters are powerful: If an ACL rule shows 0 matches when you expect traffic to be hitting it, the ACL may be applied to the wrong interface or in the wrong direction. If the implicit deny is hitting (visible only via show ip access-lists with a log keyword), legitimate traffic is being dropped unintentionally.

10. Removing ACLs from Interfaces

Removing an ACL from an interface does not delete the ACL definition — it only detaches it from that interface. Traffic filtering stops immediately on that interface when the binding is removed.

! Remove ACL from inbound direction of GigabitEthernet0/0
Router(config)# interface GigabitEthernet0/0
Router(config-if)# no ip access-group 10 in

! Remove named ACL from outbound direction of GigabitEthernet0/1
Router(config)# interface GigabitEthernet0/1
Router(config-if)# no ip access-group BLOCK_TELNET out

! Remove ACL from VTY lines
Router(config)# line vty 0 4
Router(config-line)# no access-class 5 in

Difference between removing from interface vs deleting: no ip access-group 10 in only removes the binding — ACL 10 still exists in the configuration. To also delete the ACL itself, use no access-list 10 (numbered) or no ip access-list extended BLOCK_TELNET (named). Always remove from all interfaces before deleting — deleting an applied ACL may cause unexpected behaviour.

11. ACL Interaction with NAT, QoS, and Firewalls

NAT: On routers, ACLs are evaluated before NAT for inbound traffic and after NAT for outbound traffic. This means inbound ACLs on the outside interface see pre-NAT (public) addresses; outbound ACLs on the inside interface see post-NAT (private) addresses. Misunderstanding this order is a common NAT+ACL misconfiguration. See: Static NAT | Dynamic NAT
QoS (Quality of Service): ACLs can classify traffic for QoS policies using class-map match-access-group. The ACL identifies the traffic and the QoS policy applies bandwidth, priority, or marking to it.
Zone-Based Firewall (ZBF): Cisco ZBF uses class-maps and policy-maps rather than ACLs directly, but ACLs can be used within class-map match criteria to identify traffic for zone policies. ZBF provides stateful inspection; ACLs alone are stateless. See: Zone-Based Firewall Basics
IPsec VPN: Crypto ACLs define "interesting traffic" that triggers IPsec encryption. These are referenced by the crypto map but are not applied to interfaces via ip access-group. See: Site-to-Site IPsec VPN

NAT and ACL Processing Order

  INBOUND packet (arriving on outside/WAN interface):
  Packet → [Inbound ACL checks PUBLIC source] → Routing → NAT translates to PRIVATE
  
  OUTBOUND packet (leaving inside/LAN interface toward WAN):
  Packet → Routing → NAT translates to PUBLIC → [Outbound ACL checks PUBLIC destination]
  
  ⚠️  Result: Inbound ACLs on outside interfaces must match PUBLIC (pre-NAT) addresses.
              Outbound ACLs on inside interfaces must match PRIVATE (post-NAT) addresses.

12. Troubleshooting ACL Application Issues

Symptom	Likely Cause	Diagnosis & Fix
ACL blocks all traffic, not just intended traffic	Missing `permit any` at end of ACL — implicit deny blocking everything	Check `show access-lists` for hit counts; add `permit ip any any` (extended) or `permit any` (standard) at end
ACL has no effect — traffic not being filtered	ACL not applied to interface, or applied in wrong direction	Run `show ip interface <int>` to confirm ACL name/number and direction; check if traffic enters on a different interface than expected
Wrong traffic being blocked	Incorrect wildcard mask or wrong source/destination in ACE	Review ACL with `show access-lists`; verify wildcard mask matches intended subnet; test with `debug ip packet` carefully
ACL applied but counters show 0 matches	Traffic is not reaching this interface/direction; routing may send traffic elsewhere	Trace the actual packet path with `traceroute`; confirm routing sends traffic through the expected interface with `show ip route`
New ACL overwrote previous ACL silently	Applied second ACL in same direction on same interface — overwrites without warning	Remember: one ACL per direction per interface. Check `show ip interface` to see what is currently applied
Legitimate management traffic blocked (can't SSH to router)	Inbound ACL on the interface the management host reaches the router through is too restrictive	Ensure the ACL permits the management host's IP to the router's IP on port 22; or use `access-class` on VTY lines instead of interface ACLs for management

Useful troubleshooting sequence:

! Step 1: Confirm ACL is applied and in which direction
Router# show ip interface GigabitEthernet0/0

! Step 2: Check ACL entries and hit counts
Router# show access-lists

! Step 3: Verify routing sends traffic through the expected interface
Router# show ip route 10.30.30.0

! Step 4: Clear counters and retest to get fresh hit counts
Router# clear ip access-list counters

! Step 5: Use extended ping to test specific source addresses
Router# ping 10.30.30.10 source 10.20.20.5

See: Troubleshooting ACL Misconfigurations (Step-by-Step)

13. Performance Considerations

ACLs on Cisco routers and switches are typically processed in hardware (TCAM — Ternary Content Addressable Memory) on modern platforms, making them very fast. However, there are still performance factors to be aware of:

ACE order matters: ACLs are evaluated top to bottom, stopping at the first match. Place the most frequently matched rules near the top to reduce unnecessary comparisons. Put deny rules for common attack traffic first.
Large ACLs on older hardware: Software-processed ACLs (older IOS, low-end devices) can consume significant CPU — keep ACLs as concise as possible.
Logging impacts performance: Adding the log keyword to ACE entries causes matched packets to be software-processed for syslog generation — avoid logging on high-traffic rules in production unless necessary for troubleshooting.
Use remark for documentation: Remarks add readability without any performance impact — always document ACL purpose and date modified.

! Well-documented, ordered ACL example
Router(config)# ip access-list extended PERIMETER-POLICY
Router(config-ext-nacl)# remark === Block common attack traffic first ===
Router(config-ext-nacl)# deny tcp any any eq 4444           ! Block Metasploit default
Router(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any ! Block RFC1918 from outside
Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any
Router(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any
Router(config-ext-nacl)# remark === Permit legitimate services ===
Router(config-ext-nacl)# permit tcp any host 203.0.113.10 eq 443  ! HTTPS to web server
Router(config-ext-nacl)# permit tcp any host 203.0.113.10 eq 80   ! HTTP to web server
Router(config-ext-nacl)# deny ip any any log                       ! Log everything else

14. Common Misconceptions About Applying ACLs

"Creating an ACL automatically filters traffic."
An ACL has zero effect until explicitly applied to an interface with ip access-group (or access-class for VTY). The ACL definition exists in memory but is completely inactive.
"You can apply multiple ACLs in the same direction on one interface."
No — only one ACL per direction per interface. If you apply a second ACL in the same direction, it silently replaces the first without any warning or error message.
"Inbound and outbound refer to traffic direction relative to the network."
Inbound and outbound are always from the router's perspective, relative to the specific interface. "Inbound on Gi0/0" means traffic arriving at Gi0/0 — even if that traffic is heading inward toward internal hosts.
"Deleting an ACL definition automatically removes it from all interfaces."
Deleting an ACL with no access-list 10 removes the definition but may leave the ip access-group 10 in reference on the interface. This can cause unexpected behaviour. Always remove the ACL from interfaces before deleting it.
"Standard ACLs should be placed close to the source for efficiency."
This is backwards. Standard ACLs should be placed close to the destination. Placing a standard ACL (which only matches source IP) close to the source would block that source from reaching all destinations — far too broad. Extended ACLs go close to the source.

15. Key Points & Exam Tips

Topic	Key Facts to Remember
Application command	`ip access-group {number\|name} {in\|out}` — must be in interface config mode
VTY management	`access-class {number\|name} in` under `line vty` — not `ip access-group`
One ACL per direction	Maximum one ACL inbound and one outbound per interface — second overwrites first silently
Inbound direction	Evaluated before routing — most efficient for dropping unwanted traffic early
Outbound direction	Evaluated after routing — packet has already been processed; filters at egress
Standard ACL placement	Close to destination — source-only filtering is too broad near the source
Extended ACL placement	Close to source — specific matching allows early filtering, saves bandwidth
Implicit deny	Always at the end of every ACL — always add a `permit` for legitimate traffic
Removal command	`no ip access-group {number\|name} {in\|out}` — removes binding, not ACL definition
Verification	`show ip interface` for applied ACLs; `show access-lists` for hit counters

16. Applying ACLs to Interfaces Quiz

1. An engineer creates a named extended ACL called RESTRICT-HR but forgets to apply it to any interface. Traffic from the HR subnet continues reaching the server. What is the most accurate explanation?

A. The ACL is automatically applied globally when created with a name B. The ACL is processing traffic but its permit rules are too broad C. Extended ACLs require a reload to activate D. An ACL has no effect until explicitly applied to an interface with ip access-group — the definition alone does nothing

Correct answer is D. In Cisco IOS, creating an ACL only defines the rules in memory — it has absolutely no effect on traffic until applied to an interface with ip access-group [name|number] {in|out}. This is one of the most common ACL mistakes: the configuration looks correct but the ACL is simply never activated.

2. A standard ACL numbered 15 is designed to block host 172.16.5.10 from accessing a file server at 10.0.0.50. Which interface and direction placement follows Cisco's best practice?

A. Inbound on the interface closest to 172.16.5.10 (the source) B. Inbound or outbound on the interface closest to 10.0.0.50 (the destination server) C. Outbound on the WAN interface D. Inbound on the loopback interface

Correct answer is B. Standard ACLs filter on source IP only — they cannot distinguish which destination the traffic is heading to. Placing ACL 15 near the source (172.16.5.10's router) would block that host from reaching all destinations, not just the file server. Placing it near the destination (10.0.0.50's interface) precisely limits the effect to only traffic destined for that server.

3. An engineer applies ACL 101 inbound on Gi0/0 and then applies ACL 102 inbound on the same Gi0/0 interface. What is the result?

A. Both ACLs are active — traffic is evaluated against both sequentially B. An error message is displayed and ACL 102 is rejected C. ACL 102 silently replaces ACL 101 — only ACL 102 is now active inbound on Gi0/0 D. The interface is placed in err-disabled state

Correct answer is C. Cisco IOS enforces a one-ACL-per-direction per-interface rule. If you apply a second ACL in the same direction, it silently overwrites the first — no warning or error message is displayed. ACL 101 is no longer active. This is a dangerous silent replacement that can leave intended filtering inactive. Always verify with show ip interface Gi0/0 after applying ACLs.

4. The following ACL is applied inbound on Gi0/0:
`access-list 50 deny host 10.1.1.5`
After applying it, all hosts — including those not in the deny — lose connectivity. What is the cause?

A. The implicit deny at the end of ACL 50 blocks all traffic not explicitly permitted — no permit any was added B. The ACL was applied in the wrong direction — it should be outbound C. Standard ACLs automatically deny all traffic when applied inbound D. The interface went down when the ACL was applied

Correct answer is A. Every ACL ends with an invisible implicit deny ip any any. ACL 50 only has one explicit entry (deny host 10.1.1.5). All other traffic falls through to the implicit deny and is dropped. The fix is to add access-list 50 permit any after the deny entry, which permits all other traffic before the implicit deny is reached.

5. An engineer wants to restrict SSH access to a router so that only the management subnet 192.168.99.0/24 can connect. Which command correctly achieves this on VTY lines 0 through 4?

A. ip access-group MGMT-ACL in under interface GigabitEthernet0/0 B. ip access-group 5 in under line vty 0 4 C. access-class 5 in under line vty 0 4, where ACL 5 permits 192.168.99.0 0.0.0.255 D. access-class 5 out under line vty 0 4

Correct answer is C. VTY line access control requires access-class (not ip access-group) under line vty configuration. The direction is in — filtering who can initiate a connection to the router. The ACL must permit the management subnet and implicitly deny everything else. Using ip access-group on a VTY line is invalid syntax and has no effect.

6. An extended ACL is configured to block HTTP (TCP 80) from host 10.5.5.5 to server 10.30.30.10. For maximum efficiency (drop traffic before it wastes WAN bandwidth), where should this ACL be applied?

A. Outbound on the router interface facing the server (10.30.30.x) B. Inbound on the router interface closest to host 10.5.5.5 (the source) C. Inbound on the loopback interface of the router D. Outbound on the WAN interface

Correct answer is B. Extended ACLs should be placed close to the source — the interface nearest 10.5.5.5. Applied inbound there, the traffic is filtered immediately upon arrival, before the router performs any routing lookup or forwards it toward the destination. This wastes no network bandwidth and reduces router processing. Inbound is also more efficient than outbound because packets are dropped before routing occurs.

7. After applying an ACL, the `show access-lists` command shows 0 matches on all entries, but the traffic that should be filtered is still getting through. What is the most likely explanation?

A. The ACL counters need to be manually enabled with a separate command B. The implicit deny is matching all traffic before the explicit rules C. The ACL entries have syntax errors and are being skipped D. The traffic is not traversing the interface where the ACL is applied — routing sends it via a different path

Correct answer is D. Zero matches with traffic still passing means the traffic is taking a different path — it never crosses the interface where the ACL is applied. Use show ip route [destination] to verify the routing path and traceroute to confirm which interfaces the traffic actually traverses. The ACL may be applied to the correct interface in theory but routing bypasses it in practice.

8. A router has an ACL applied inbound on its outside interface (connected to the internet). The ACL allows inbound TCP traffic to the public IP 203.0.113.10 on port 443. NAT translates this to the private server 10.0.0.100:443. In the ACL entry, which IP address must be specified as the destination?

A. 203.0.113.10 — the public IP, because inbound ACLs on the outside interface evaluate traffic before NAT translation B. 10.0.0.100 — the private IP, because NAT happens before the ACL is evaluated C. Either IP works — Cisco automatically handles NAT/ACL interaction D. The MAC address of the server must be used instead

Correct answer is A. On a router, inbound ACLs are evaluated before NAT translation for traffic arriving from outside. The packet arrives with the public destination IP (203.0.113.10) — NAT has not yet translated it to the private address. Therefore, the ACL must match the public IP. After the ACL permits the packet, NAT translates it to 10.0.0.100. Confusing this order is a very common NAT+ACL misconfiguration.

9. Which command correctly removes a named ACL called FILTER-OUT from the outbound direction of interface GigabitEthernet0/1 without deleting the ACL definition?

A. no ip access-list extended FILTER-OUT B. no access-group FILTER-OUT out C. no ip access-group FILTER-OUT out entered under interface GigabitEthernet0/1 D. remove ip access-group FILTER-OUT out

Correct answer is C.

no ip access-group FILTER-OUT
                  out

entered in interface configuration mode removes the binding between the interface and the ACL — the ACL definition still exists in the running config. Option A (no ip access-list extended FILTER-OUT) deletes the ACL definition entirely from the router, which would also affect any other interface using it. Options B and D use invalid command syntax.

10. A network engineer uses `show ip interface GigabitEthernet0/0` and sees: "Inbound access list is not set" and "Outbound access list is not set" — even though the running config shows `ip access-group 110 in` under that interface. What is the most likely cause?

A. The ACL must be reapplied after each reboot B. ACL 110 was deleted with no access-list 110 after being applied — the binding reference remains but the ACL definition is gone C. The interface is in shutdown state so ACLs are not shown D. ACL 110 is a standard ACL and cannot be applied to GigabitEthernet interfaces

Correct answer is B. When an ACL is deleted with no access-list 110, the definition is removed from memory. However, the ip access-group 110 in line may remain in the interface config. Since the ACL no longer exists, show ip interface shows "not set" — effectively the interface has no active ACL even though the config line is present. This is why you should always remove an ACL from its interface(s) before deleting the definition itself.

← Back to Home

Applying ACLs to Interfaces

1. Why Apply ACLs to Interfaces?

2. Inbound vs. Outbound ACLs

Packet Processing Flow — Inbound vs. Outbound

3. Interface Types Where ACLs Can Be Applied

4. The ip access-group Command — Syntax and Usage

Command Syntax

Applying a Numbered Standard ACL Inbound

Applying a Numbered Extended ACL Outbound

Applying a Named ACL

Applying Both Inbound and Outbound on the Same Interface

5. ACL Placement Rules — Standard vs. Extended

Standard ACL — Place Close to the Destination

Extended ACL — Place Close to the Source

Placement Summary

6. The Implicit Deny and Its Impact

7. Applying ACLs to VTY Lines (Management Access Control)

8. Real-World Scenario — Full ACL Application Walkthrough

Implementation

9. Verifying ACL Application

Key Verification Commands

Sample show ip interface Output

Sample show access-lists Output with Hit Counters

10. Removing ACLs from Interfaces

11. ACL Interaction with NAT, QoS, and Firewalls

NAT and ACL Processing Order

12. Troubleshooting ACL Application Issues

13. Performance Considerations

14. Common Misconceptions About Applying ACLs

15. Key Points & Exam Tips

16. Applying ACLs to Interfaces Quiz

1. An engineer creates a named extended ACL called RESTRICT-HR but forgets to apply it to any interface. Traffic from the HR subnet continues reaching the server. What is the most accurate explanation?

2. A standard ACL numbered 15 is designed to block host 172.16.5.10 from accessing a file server at 10.0.0.50. Which interface and direction placement follows Cisco's best practice?

3. An engineer applies ACL 101 inbound on Gi0/0 and then applies ACL 102 inbound on the same Gi0/0 interface. What is the result?

4. The following ACL is applied inbound on Gi0/0: access-list 50 deny host 10.1.1.5 After applying it, all hosts — including those not in the deny — lose connectivity. What is the cause?

5. An engineer wants to restrict SSH access to a router so that only the management subnet 192.168.99.0/24 can connect. Which command correctly achieves this on VTY lines 0 through 4?

6. An extended ACL is configured to block HTTP (TCP 80) from host 10.5.5.5 to server 10.30.30.10. For maximum efficiency (drop traffic before it wastes WAN bandwidth), where should this ACL be applied?

7. After applying an ACL, the show access-lists command shows 0 matches on all entries, but the traffic that should be filtered is still getting through. What is the most likely explanation?

9. Which command correctly removes a named ACL called FILTER-OUT from the outbound direction of interface GigabitEthernet0/1 without deleting the ACL definition?

10. A network engineer uses show ip interface GigabitEthernet0/0 and sees: "Inbound access list is not set" and "Outbound access list is not set" — even though the running config shows ip access-group 110 in under that interface. What is the most likely cause?

4. The following ACL is applied inbound on Gi0/0:
`access-list 50 deny host 10.1.1.5`
After applying it, all hosts — including those not in the deny — lose connectivity. What is the cause?

7. After applying an ACL, the `show access-lists` command shows 0 matches on all entries, but the traffic that should be filtered is still getting through. What is the most likely explanation?

10. A network engineer uses `show ip interface GigabitEthernet0/0` and sees: "Inbound access list is not set" and "Outbound access list is not set" — even though the running config shows `ip access-group 110 in` under that interface. What is the most likely cause?