Cisco ACL Builder

Build Cisco extended access lists with correct wildcard masks, explicit logging and the implicit-deny behaviour made visible.

Config generator Cisco Runs in your browser
CIDR, "any" or a single host.
Single, list (80 443) or range (5000-5010).
Try:

Result

ACL
GUEST-OUT
Rule
permit tcp 10.50.0.0 0.0.0.255 any eq 443
Source wildcard
10.50.0.0 0.0.0.255
Applied
Gi0/1 in
Cisco IOS
ip access-list extended GUEST-OUT
 remark Generated by Netvorx Tools
 permit tcp 10.50.0.0 0.0.0.255 any eq 443
 deny ip any any log
!
interface Gi0/1
 ip access-group GUEST-OUT in
!
Verification
show ip access-lists GUEST-OUT
show ip interface Gi0/1 | include access list
clear ip access-list counters GUEST-OUT
The implicit deny
Every ACL ends with an invisible "deny ip any any". The explicit deny with logging above makes it visible so drops appear in the log instead of vanishing - the single most useful habit when debugging an ACL.
Editing safely
Named ACLs are edited in place, and on older IOS re-applying a list can briefly drop traffic. Use sequence numbers to insert rules, and test from a console session when the ACL protects your management path.

About Cisco ACL Builder

Cisco ACLs use wildcard masks, evaluate top to bottom, stop at the first match and end with an invisible deny. Every one of those four facts causes outages. This builder handles the mask conversion and makes the implicit behaviour explicit.

Ordering and sequence numbers

Named ACLs support sequence numbers, and using them is the difference between a safe edit and an outage. Insert with an explicit sequence (15 permit ...) to place a rule precisely, and use resequence to reopen gaps once numbering gets tight. Reordering by deleting and re-adding leaves the ACL briefly incomplete on some platforms, which on a production interface means dropped traffic for the duration of the edit.

Order and direction

Rules are evaluated in order and the first match wins - so a broad permit above a specific deny makes the deny dead code. Direction is from the router's perspective: in filters traffic arriving on the interface, out filters traffic leaving it. Filtering inbound on the interface closest to the source is both cheaper and easier to reason about.

Common use cases

  • Restricting a guest VLAN to web traffic only.
  • Blocking a specific protocol during an incident.
  • Building a management-plane filter for SSH and SNMP sources.

Edge cases and gotchas

  • Applying an ACL to the interface you are connected through can lock you out - always permit your own management access first.
  • ACL logging is CPU-intensive on hardware-forwarded platforms; use it for diagnosis, not permanently.

Frequently asked questions

Why does my permit rule never match?
Almost always an earlier rule matched first, or the wildcard mask is wrong. Check the hit counters with "show ip access-lists" - a rule with zero hits is never being reached.
Do I need to permit return traffic?
For a stateless ACL, yes - or use the "established" keyword for TCP, which matches packets with ACK or RST set. Zone-based firewall or reflexive ACLs give you real statefulness.