Cisco ACL Generator
Generate Cisco ACL commands from IPv4 flow rows for IOS, NX-OS, and ASA with platform-aware address conversion and safety checks before use.{{ result.summary.heading }}{{ result.summary.primary }}{{ result.summary.line }}{{ badge.label }}
{{ result.configText }}
| Seq | Action | Protocol | Source | Source port | Destination | Destination port/type | Logging | Remark | Copy |
|---|---|---|---|---|---|---|---|---|---|
| {{ row.sequence }} | {{ row.action }} | {{ row.protocol }} | {{ row.source }} | {{ row.sourcePort }} | {{ row.destination }} | {{ row.destinationPort }} | {{ row.logging }} | {{ row.remark }} |
| Check | Status | Action | Evidence | Review note | Copy |
|---|---|---|---|---|---|
| {{ row.check }} | {{ row.status }} | {{ row.action }} | {{ row.evidence }} | {{ row.note }} |
| Setting | Value | Generated effect | Review note | Copy |
|---|---|---|---|---|
| {{ row.setting }} | {{ row.value }} | {{ row.effect }} | {{ row.note }} |
An IPv4 access control list is an ordered policy, not a bag of independent firewall rules. Each access control entry (ACE) tests packet fields and stops evaluation when it matches. A correct permit placed below a broader matching deny is unreachable; a broad permit near the top can make later restrictions ineffective.
Standard and extended ACLs express different amounts of intent. A standard ACL matches only the source address. An extended ACL can also match protocol, destination, TCP or UDP ports, ICMP type, options, and logging. Choosing the narrower syntax for a destination-sensitive policy discards information even when every source row looks reasonable.
- Wildcard mask
- A zero bit must match the corresponding address bit; a one bit may vary. This is the inverse of a contiguous subnet mask in IOS-style ACL syntax.
- First match
- The earliest matching ACE decides permit or deny, so row order changes policy behavior.
- Implicit deny
- Traffic not permitted by an earlier ACE is denied at the end even when no final deny line is visible.
- Object group
- A named address or service set that must already exist on the target device and be supported by its syntax.
Platform syntax also changes the command projection. IOS and IOS XE use wildcard masks for network terms, NX-OS output uses IPv4 prefixes, and ASA output uses subnet masks in flat access-list commands. Sequence prefixes, standard ACLs, numbered ACLs, service object groups, and log-input are not interchangeable across those targets.
Risk is wider than syntax. An any-any permit, broad management-service exposure, an unlogged deny, or a missing remark may parse successfully and still be a poor change. Logging every denial can be harmful too because busy ACLs can create avoidable CPU and syslog load.
Generated commands cannot establish interface direction, attachment point, existing object-group definitions, software-train behavior, time-range availability, or the safety of the surrounding rules. Review the complete device policy and keep a recovery path before applying an ACL to live traffic.
How to Use This Tool:
Define the target syntax and policy shape before entering flows; those choices decide what can be emitted safely.
- Choose Platform target, ACL type, and Identifier mode. Use an extended ACL for protocol, destination, or service matching.
- Enter the ACL identifier. Named identifiers accept letters, numbers, underscore, period, colon, and hyphen; numbered output is limited to IOS and checked against the selected ACL type.
- Paste or load Flow rows. Keep one policy row per line, with an optional CSV header. Use
any, a host, an IPv4 CIDR, wildcard syntax, or an allowed network object group for addresses. - Choose the Review profile and Object-group handling. Strict profiles flag broad scope sooner, while object-group choices decide whether unresolved network or service names are accepted.
- Set the Sequence strategy, remarks, and logging. Leave Explicit terminal deny off unless the change standard requires a visible logged final deny.
- Do not paste commands while Fix before using the ACL is shown. When generation succeeds, compare the ACL config with the ACE ledger, safety review, and target assumptions before testing it in the intended device context.
Interpreting Results:
ACE count is the number of packet-matching lines after multi-port expansion; remark lines and headers are separate. A source row containing several source and destination ports can therefore create more than one ACE while retaining a single original policy row.
| Status | Meaning | Response |
|---|---|---|
| Blocked | A row, identifier, address, service, expansion, or platform combination is invalid. | Correct the named input; no generated config is safe to use. |
| Risk | A strict review found a consequential condition such as broad scope, unlogged denies, or management exposure. | Narrow or reorder the policy, then repeat the review. |
| Review | The syntax can be generated, but the condition needs a human decision. | Verify the evidence against the change request and target device. |
| Ready or Info | The local rule passed or records a neutral platform fact. | Continue with device-side syntax and attachment testing. |
Technical Details:
CIDR input is normalized to its network address before platform syntax is emitted. A /32 becomes a host term and /0 becomes any. Explicit wildcard input may be noncontiguous for IOS or ASA, but NX-OS prefix output requires the implied mask to be contiguous.
Formula Core:
For a contiguous IPv4 prefix of length p, the IOS wildcard is the bitwise inverse of the subnet mask. The equivalent integer has one bit for every host position.
Review breadth adds the number of variable source and destination address bits. It is a local screening measure, not a count of packets or proof that an ACE is unsafe.
A host contributes 0 variable bits, a CIDR contributes 32 − p, any contributes 32, and explicit wildcard syntax contributes the number of one bits. An object-group address is assigned 12 bits for this review heuristic because its members are not expanded locally.
Rule Core:
| Stage | Deterministic rule |
|---|---|
| Parse | The first non-comment row may be a recognized header. Without a header, fields use action, protocol, source, destination, destination port, remark, log, source port, and option order. |
| Normalize | Action aliases become permit or deny; all and any protocols become ip; addresses and service operands are validated for the chosen platform. |
| Expand | Comma-separated source and destination ports form a Cartesian product. One source row may create at most 40 ACEs, and the complete ACL may contain at most 300 ACEs. |
| Emit | Input order is preserved. An enabled remark is placed immediately before its ACEs, and sequence values advance across both remarks and ACEs. |
| Terminate | An optional explicit deny is appended with logging. If omitted, the platform's implicit deny still controls unmatched traffic. |
| Target | Address form | Supported projection |
|---|---|---|
| IOS / IOS XE | Network plus wildcard mask | Named or numbered; standard or extended; named sequences; log-input; service object groups |
| NX-OS | IPv4 CIDR prefix | Named extended output with sequences; no numbered, standard, service-object-group, or log-input projection |
| ASA | Network plus subnet mask | Flat named extended access-list lines without sequences; service object groups allowed; log-input reduced to log |
| Review profile | Broad when B is at least | Additional emphasis |
|---|---|---|
| Balanced change review | 32 bits | Remarks expected |
| Strict edge ingress | 24 bits | Strict status and explicit deny recommended |
| Internal segmentation | 28 bits | Strict status and explicit deny recommended |
| Management plane access | 24 bits | Broad-source management permits receive a dedicated risk check |
| Migration staging | 36 bits | Remarks and explicit deny are not required by the profile |
Any-any ACEs are tracked separately from the breadth threshold. IOS numbered standard ACLs accept 1 to 99 or 1300 to 1999; numbered extended ACLs accept 100 to 199 or 2000 to 2699. Numeric protocols span 0 to 255, numeric ports span 1 to 65535, sequence starts span 1 to 2,147,483,647, and sequence steps span 1 to 1,000,000. Remarks longer than 100 characters are shortened with a warning.
The safety review also checks a broad terminal rule before later rows, permit coverage, deny logging, remark coverage, multi-port expansion, object-group references, explicit terminal behavior, and permits from any source to common management services. These are review heuristics and do not replace device configuration validation.
Security Review Limits:
Flow text is processed in the browser, but a valid draft can still interrupt traffic or expose a service. Test the commands against the exact platform and software release, inspect the existing ACL and attachment direction, confirm referenced objects and time ranges, estimate logging volume, and arrange console or out-of-band recovery before deployment.
References:
- ACLs Configuration Guide: Access Control Lists, Cisco IOS XE 17, Cisco.
- Creating an IP Access List and Applying It to an Interface, Cisco IOS XE 16.12, Cisco.
- Configuring Logging for Access Lists, Cisco ASA Series, Cisco.
- Guidelines on Firewalls and Firewall Policy, NIST SP 800-41 Rev. 1, September 2009.