An ACL interview question often starts with “standard or extended?” and ends with a packet that unexpectedly disappears. The useful answer connects match fields, rule order, interface direction and the traffic that was never explicitly permitted.
Short answer: A classic IPv4 interface access control list is an ordered packet filter: the first matching entry decides permit or deny, and packets that match no entry are denied implicitly.[1] A standard IPv4 ACL matches the source address; an extended ACL can also match destination address, protocol and TCP/UDP ports.[1]
Standard vs extended ACL: what is the difference?
This article uses Cisco IOS-style IPv4 routed-interface ACLs; do not assume identical syntax or defaults for every firewall, cloud policy or IPv6 implementation.
| Question | Standard IPv4 ACL | Extended IPv4 ACL |
|---|---|---|
| Which address fields can it match? | Source address | Source and destination addresses |
| Can it select TCP versus UDP? | Not as a protocol match | Yes |
| Can it restrict a destination TCP port? | No | Yes |
| Can it express “this subnet to this server on TCP/22 only”? | No | Yes |
These match-field differences follow Cisco's description of standard and extended IP ACLs.[1] Names versus numbers are a separate naming choice: a named ACL can still be standard or extended.[1]
Design recommendation: write the requirement as source → destination → protocol → destination port before choosing an ACL type. If the requirement contains a particular server and service, start with an extended ACL rather than trying to make a source-only filter express it.
First match and implicit deny: the packet decision
Cisco evaluates entries in order and stops at the first match; a later, more specific entry does not override an earlier match.[1] An explicit permit is therefore necessary for traffic that should survive an otherwise restrictive ACL.[1]
Packet reaches the interface and direction where this ACL is attached
→ First entry matches? Apply its permit/deny action; stop
→ Otherwise try the next entry
→ No entry matches? Implicit deny
The sequence above describes the ACL decision, not the complete forwarding pipeline: a permit is not a guarantee of application success.
For example, this deliberately incorrect ordering cannot block the selected source, because the first line already permits every source.[1]
access-list 10 permit any
access-list 10 deny host 192.0.2.44
Review habit: check for an earlier broad permit before adding another deny. Check for an earlier broad deny before adding another permit. Put rules in the order required by the policy, not merely in the order they were requested.
Practical example: allow one subnet to one SSH server
Fictional lab requirement: clients in 192.0.2.0/24 may reach server 198.51.100.10 on TCP destination port 22; deny all other IPv4 traffic entering the router from that client segment. These are example addresses, not a production design. The router CLI below is illustrative and has not been executed on a router.
Clients 192.0.2.0/24
|
| enters router GigabitEthernet0/0
v
LAB router -------- Server 198.51.100.10
ip access-list extended CLIENTS-SSH-ONLY
permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 22
deny ip any any
!
interface GigabitEthernet0/0
ip access-group CLIENTS-SSH-ONLY in
The wildcard 0.0.0.255 selects the example /24 source range, host selects a single destination address, and the port condition after the destination selects the destination port.[1]
The explicit deny ip any any makes the final policy visible; unmatched IPv4 packets would already be blocked by the implicit deny.[1]
The interface attachment applies the filter inbound: to packets arriving at that router interface, not to an abstract “inbound toward the server” direction.[1]
Important scope warning: this lab deliberately blocks everything else entering from the client segment, not just other traffic to the SSH server. Do not paste it onto a production user VLAN without inventorying DNS, address assignment, management and other dependencies. Prepare console/out-of-band access and a rollback before changing an ACL on your management path.
Predict the result before touching the router
These are expected outcomes derived from the fictional rule set, not captured router results.
| Packet entering the client-facing interface | Expected result | Why |
|---|---|---|
| 192.0.2.44 → 198.51.100.10, TCP destination 22 | Permit | Matches the permitted tuple |
| 192.0.2.44 → 198.51.100.10, TCP destination 443 | Deny | Wrong destination port |
| 192.0.2.44 → 198.51.100.11, TCP destination 22 | Deny | Wrong destination host |
| 203.0.113.44 → 198.51.100.10, TCP destination 22 | Deny | Wrong source range |
| 192.0.2.44 → 198.51.100.10, ICMP echo request | Deny | Wrong protocol |
A failed ping is therefore consistent with this specific policy. Test the service you actually permitted rather than using ICMP as the only acceptance test.
Return traffic: an ACL is not automatically a stateful firewall
In this example, the server's reply travels in the opposite direction and does not enter the client-facing interface, so that interface's inbound ACL is not the return-path filter. If another interface ACL filters the return path, evaluate that policy separately.
For a sample SSH connection, reason about both tuples:
Request: 192.0.2.44:49152 → 198.51.100.10:22
Reply: 198.51.100.10:22 → 192.0.2.44:49152
Cisco's TCP established ACL keyword checks for ACK or RST bits.[1]
Do not describe that flag test as proof that the router has tracked a legitimate session: the classic extended ACL rule is not a state table. For a policy that should admit only actual session return traffic, evaluate a stateful firewall rather than treating a TCP flag shortcut as equivalent protection.
Troubleshooting checklist: “the ACL looks right, but SSH fails”
Use the following as an investigation order, not as a claim that every failure is an ACL problem.
- Identify the actual tuple. Record observed source, destination, protocol and destination port; do not rely only on the intended addresses.
- Check the attachment. Confirm the correct interface, ACL name and
in/outdirection. - Read every earlier entry. First-match processing makes rule order decisive.[1]
- Compare wildcard and port placement. Verify that the rule selects the intended source range and destination service.
- Test a new connection and inspect counters. Compare before and after; do not immediately clear evidence from a shared device.
- Walk the return path separately. Check other filters, routing and the destination service.
- Run a negative test. A working SSH connection alone does not show that unwanted traffic is blocked.
Illustrative IOS-style read-only checks; command support and counter presentation vary by platform:
show ip interface GigabitEthernet0/0
show ip access-lists CLIENTS-SSH-ONLY
show running-config interface GigabitEthernet0/0
show ip route 198.51.100.10
Avoid starting with broad packet debugging on a production router: Cisco warns that debug commands consume resources and can disrupt a heavily loaded system.[1]
Common interview pitfalls
- “The most specific ACL entry wins.” No: the first matching entry wins.[1]
- “No explicit deny means permit.” No: unmatched traffic reaches the implicit deny.[1]
- “Standard means numbered; extended means named.” These are different classifications.[1]
- “Permit TCP/22 also permits ping.” The protocol match does not include ICMP.[1]
- “Any ACL deny always drops a packet.” Context matters: an ACL used to select debug traffic is not an interface forwarding filter.[1]
- “I can ignore routing protocols when applying an interface ACL.” Cisco specifically cautions against unintentionally filtering routing updates with an inbound ACL.[1]
A concise interview answer
“A classic IPv4 interface ACL is an ordered set of permit and deny entries. Standard ACLs match the source address; extended ACLs can also match the destination, protocol and ports. The first match wins, and unmatched traffic is implicitly denied.”[1]
“For a subnet allowed to SSH to one server, I would use an extended ACL, explicitly identify the interface direction, and validate both the permitted connection and denied alternatives. I would inspect the return path separately and have a rollback before applying the policy.”
Summary and related reading
Remember fields → order → attachment → return path. First predict which rule should match; then test whether the actual packets follow that prediction.
- Stateful vs Stateless Firewall Explained
- Zone-Based Firewall: Class-Map, Policy-Map and Service-Policy
- NAT vs PAT vs Static NAT vs DNAT
Preparing for a network engineering interview? Explain the five test packets above without looking at the answers, then change the requirement to “deny only SSH and allow other IPv4 traffic” and describe how the rule order and final action must change.
Post a Comment