// Guide · Security

Firewall ACL Planner

Design your firewall policy once in a vendor-neutral format, then export it as production-ready CLI for any of five major firewall platforms. Includes pre-built VCF perimeter templates (NSX Edge, ESXi management, backup, ToR switches) and shadow-rule detection so unreachable rules surface before deployment.

Palo AltoCisco ASA / FTDJuniper SRXFortinetShadow DetectionVCF Templates

Open the tool Jump to walkthrough

Quick start

Pick a VCF template — NSX Edge Perimeter, ESXi-Mgmt, AD-Servers, Backup Network, or build from blank.
Add or edit rules — set source zone, destination zone, ports/services, action (permit/deny). Vendor-neutral form.
Watch for shadow detection — the tool flags any rule that's unreachable due to an earlier rule consuming its traffic.
Pick your firewall vendor — Palo Alto PAN-OS, Cisco ASA, Cisco FTD, Juniper SRX, or Fortinet.
Export the CLI config — copy/paste into your firewall, or save for change management.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Examples
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool when you need to:

Design perimeter ACLs for a new VCF deployment — protect management, vSAN, vMotion, NSX TEP, and backup networks at the physical firewall.
Migrate firewall rules between vendors — author once, export to whichever platform you're moving to.
Standardise rule design across multiple firewalls from different vendors — same logical policy, vendor-specific syntax.
Catch shadow rules early — before a permit gets buried under a broader deny and silently fails.
Document the rule intent in a portable format for change advisory board reviews.

ℹ

This is for north-south / perimeter firewalls For NSX Distributed Firewall (east-west, intra-VCF), use the NSX Firewall Builder instead.

How it works

Firewall vendors have different syntax but the same conceptual model: rules with source, destination, service, and action, evaluated top-down with first-match semantics. This tool authors at the conceptual layer and translates to vendor syntax on export.

You define zones (logical groupings like VCF-Mgmt, NSX-Edge, Workloads, Internet), address objects (specific subnets/hosts), and service objects (named TCP/UDP port groups). Rules reference these by name.

The shadow detector walks the rule list looking for rules that can never match — typically because an earlier rule with broader scope already permits or denies the same traffic.

Step-by-step walkthrough

1. Pick a VCF template (or start blank)

Templates available:

NSX Edge Perimeter — typical north-south policy for VCF edge connectivity (BGP, VPN, NAT)
ESXi-Mgmt — management plane access (SSH, HTTPS to vCenter, ESXi management)
AD-Servers — restrictive policy for AD/LDAP/Kerberos servers
Backup Network — backup target access (SMB, NFS, backup-vendor ports)
ToR-Switches — management VLAN access for switches (SNMP, syslog, NetFlow)
Default Deny — empty policy with explicit drop-all at the bottom

2. Define zones and address objects

Click the Zones tab. Add zones for each network segment (e.g. VCF-Mgmt, vSAN, NSX-Edge, Internet, WLD-Prod).

Click the Address Objects tab. Add named objects for specific hosts/subnets:

vCenter — single host IP
SDDC-Manager — single host IP
VCF-Mgmt-Net — CIDR subnet
AD-Servers — group of multiple IPs

3. Add rules

Each rule has:

Order — rule position (first match wins)
Source zone + address — where the traffic comes from
Destination zone + address — where it's going
Service — TCP/UDP ports or protocol (SSH, HTTPS, custom port range)
Action — Permit or Deny
Logging — log matches (recommended for any deny rule)
Description — what does this rule do? (lifesaver during audits)

4. Run shadow detection

The Validate panel runs as you type. Common findings:

Shadow rule — rule X is unreachable because rule Y (above it) catches the same traffic
Missing default deny — no explicit drop-all at the bottom (vendor default may be permit)
Any-any rules — rule with Any source AND Any destination AND Any service is rarely correct

5. Pick your vendor

Choose the platform you'll deploy to: Palo Alto PAN-OS, Cisco ASA, Cisco FTD, Juniper SRX, or Fortinet FortiGate. Each vendor has slightly different idioms — addresses inline vs. object-group references, named services vs. inline port specs. The tool emits idiomatic config for each.

6. Export and review

The full vendor config appears in the export panel. Review it against your standards (logging destinations, NAT rules, interface assignments — those are out of scope). Copy or download.

Examples

Example · ESXi management ACL

Source: VCF-Mgmt zone. Destination: ESXi-Hosts address group. 5 rules:

1. Permit  Mgmt → ESXi  TCP/443  (ESXi Web UI)
2. Permit  Mgmt → ESXi  TCP/22   (SSH for break-glass)
3. Permit  Mgmt → ESXi  TCP/902  (vSphere Client legacy)
4. Permit  Mgmt → ESXi  ICMP echo  (ping monitoring)
5. Deny    Any → ESXi   Any        (default deny, log)

Example · NSX Edge perimeter

NSX edge needs to talk BGP to the physical fabric and forward workload traffic to the internet:

1. Permit  NSX-Edge → ToR-Switches  TCP/179   (BGP)
2. Permit  Workloads → Internet      TCP/80,443 (HTTP/HTTPS egress)
3. Permit  Workloads → DNS-Servers   UDP/53    (DNS)
4. Deny    Internet → VCF-Mgmt       Any (log) (no internet → mgmt)
5. Deny    Any → Any                 Any (log) (catch-all)

Common mistakes

🚨

No explicit default deny Some vendors default to "deny all at end" automatically; older Cisco IOS defaults to permit. Always add an explicit deny-all-with-logging at the bottom — makes intent unambiguous and gives visibility into what's being dropped.

🚨

Permit Any/Any/Any A permit rule with Any source, Any destination, Any service typically defeats the entire firewall. The tool flags these. Common cause: someone added a "temporary" rule for testing and forgot to remove it.

⚠

Forgetting return traffic Stateful firewalls handle return traffic automatically. Stateless ACLs (older Cisco IOS) need explicit reverse rules. The exported config is appropriate for the chosen vendor — but verify your platform's state-tracking is enabled.

⚠

Trusting source IPs from the internet Source IPs in inbound internet rules can be spoofed. Permit by source IP only when you control both ends or use anti-spoofing checks (uRPF). For administration access from arbitrary internet, use VPN, not source-IP rules.

Tools that pair well with Firewall ACL Planner:

FAQ

Does the tool know my firewall's existing rule base?

No — it generates a fresh policy. For brownfield, merge the generated rules into your existing policy manually, or design just the new rules and append them.

Can I import existing rules from a firewall config?

Not currently. The tool authors fresh policies; rule import is on the roadmap.

What about NAT rules?

Out of scope. The tool focuses on access control. NAT rules are vendor-specific and tightly coupled to your routing topology — design those separately.

Does the export include logging configuration?

Each rule's logging flag translates to the vendor's log syntax (e.g. log on Cisco, log session-end on Juniper). Configure the logging destination separately on the firewall.

How does shadow detection work?

Walks rules in order, tracking what address/service combinations earlier rules have already matched. If a later rule's match conditions are entirely covered by earlier rules, it's flagged. Doesn't catch all logical issues but catches the common ones.