AI-zone firewall design: viewer, simulator and set-command checker
A PAN-OS zone for AI agents on a lab firewall, staged as 350 set commands, with the offline checker that verified every line.
A sanitized viewer of a lab firewall design (addresses, names and ports replaced with documentation values), a client-side simulator of first-match rule evaluation over its 12 rules, and the lab's offline set-command checker ported to the browser. Nothing you type leaves this page; this is not PAN-OS.
static page; the checker and simulator load their data once JavaScript runs
The design
What the sample file builds: zone lan on port 1 (static address, default route to the ISP router) and zone ai on port 2 (the firewall is gateway and DHCP server, clients get the sanctioned resolvers by DHCP option). Hover or focus a box or an arrow for its allowed flows.
The diagram scrolls sideways on a narrow screen.
Hover or focus a part of the diagram to read what the rules allow there.
- allowed
- denied or dropped, logged
- designed, not committed
- reserved for later
The 12 rules
Every column below is parsed from the sample file by the build, so the table and the file cannot drift. All rules log at session end; the allow rules carry the Iron Skillet Outbound profile group.
| # | Name | Zones | Source | Destination | Application | Service | Action | Simulated |
|---|---|---|---|---|---|---|---|---|
| 1 | any -> any | any | 3 predefined threat-intel lists | any | any | deny | ||
Why: Iron Skillet day-one rule: the predefined threat-intel lists come first. Iron Skillet best-practice step 1 set rulebase security rules edl-block-outbound from any set rulebase security rules edl-block-outbound to any set rulebase security rules edl-block-outbound source any set rulebase security rules edl-block-outbound destination [ panw-bulletproof-ip-list panw-highrisk-ip-list panw-known-ip-list ] set rulebase security rules edl-block-outbound source-user any set rulebase security rules edl-block-outbound category any set rulebase security rules edl-block-outbound application any set rulebase security rules edl-block-outbound service any set rulebase security rules edl-block-outbound action deny set rulebase security rules edl-block-outbound log-start no set rulebase security rules edl-block-outbound log-end yes set rulebase security rules edl-block-outbound tag Outbound set rulebase security rules edl-block-outbound description "Iron Skillet outbound block rule: the predefined known-malicious, high-risk and bulletproof IP lists" move rulebase security rules edl-block-outbound top | ||||||||
| 2 | any -> any | 3 predefined threat-intel lists | any | any | any | deny | ||
Why: The same three lists as a source. Iron Skillet set rulebase security rules edl-block-inbound from any set rulebase security rules edl-block-inbound to any set rulebase security rules edl-block-inbound source [ panw-bulletproof-ip-list panw-highrisk-ip-list panw-known-ip-list ] set rulebase security rules edl-block-inbound destination any set rulebase security rules edl-block-inbound source-user any set rulebase security rules edl-block-inbound category any set rulebase security rules edl-block-inbound application any set rulebase security rules edl-block-inbound service any set rulebase security rules edl-block-inbound action deny set rulebase security rules edl-block-inbound log-start no set rulebase security rules edl-block-inbound log-end yes set rulebase security rules edl-block-inbound tag Inbound set rulebase security rules edl-block-inbound description "Iron Skillet inbound block rule: the predefined known-malicious, high-risk and bulletproof IP lists" move rulebase security rules edl-block-inbound after edl-block-outbound | ||||||||
| 3 | ai -> lan | g-ai-nodes | g-overlay-lan-peers | any | s-udp-overlay | allowOutbound | ||
Why: The overlay's (Tailscale) direct path to two named LAN hosts on its documented UDP port. What rides inside is governed by the overlay's own policy, not the firewall. overlay firewall ports set rulebase security rules ai-overlay-lan-direct from ai set rulebase security rules ai-overlay-lan-direct to lan set rulebase security rules ai-overlay-lan-direct source g-ai-nodes set rulebase security rules ai-overlay-lan-direct destination g-overlay-lan-peers set rulebase security rules ai-overlay-lan-direct source-user any set rulebase security rules ai-overlay-lan-direct category any set rulebase security rules ai-overlay-lan-direct application any set rulebase security rules ai-overlay-lan-direct service s-udp-overlay set rulebase security rules ai-overlay-lan-direct action allow set rulebase security rules ai-overlay-lan-direct log-start no set rulebase security rules ai-overlay-lan-direct log-end yes set rulebase security rules ai-overlay-lan-direct profile-setting group Outbound set rulebase security rules ai-overlay-lan-direct tag ai-zone set rulebase security rules ai-overlay-lan-direct description "AI nodes to the two LAN peers on the overlay UDP port only (direct path). What rides inside is governed by the overlay policy" move rulebase security rules ai-overlay-lan-direct after edl-block-inbound | ||||||||
| 4 | ai -> lan | any | g-not-internet | any | any | drop | ||
Why: Nothing private beyond the firewall: RFC 1918, shared address space, link-local, multicast, reserved and this-network. set rulebase security rules ai-block-private from ai set rulebase security rules ai-block-private to lan set rulebase security rules ai-block-private source any set rulebase security rules ai-block-private destination g-not-internet set rulebase security rules ai-block-private source-user any set rulebase security rules ai-block-private category any set rulebase security rules ai-block-private application any set rulebase security rules ai-block-private service any set rulebase security rules ai-block-private action drop set rulebase security rules ai-block-private log-start no set rulebase security rules ai-block-private log-end yes set rulebase security rules ai-block-private tag ai-zone set rulebase security rules ai-block-private description "AI zone may not reach any private, CGNAT, link-local or multicast address beyond the firewall" move rulebase security rules ai-block-private after ai-overlay-lan-direct | ||||||||
| 5 | ai -> lan | g-ai-nodes | g-dns-sanctioned | dns, dns-base | application-default | allowOutbound | ||
Why: Sanctioned resolvers only. best-practice step 3 set rulebase security rules ai-dns-sanctioned from ai set rulebase security rules ai-dns-sanctioned to lan set rulebase security rules ai-dns-sanctioned source g-ai-nodes set rulebase security rules ai-dns-sanctioned destination g-dns-sanctioned set rulebase security rules ai-dns-sanctioned source-user any set rulebase security rules ai-dns-sanctioned category any set rulebase security rules ai-dns-sanctioned application [ dns dns-base ] set rulebase security rules ai-dns-sanctioned service application-default set rulebase security rules ai-dns-sanctioned action allow set rulebase security rules ai-dns-sanctioned log-start no set rulebase security rules ai-dns-sanctioned log-end yes set rulebase security rules ai-dns-sanctioned profile-setting group Outbound set rulebase security rules ai-dns-sanctioned tag ai-zone set rulebase security rules ai-dns-sanctioned description "DNS to the sanctioned resolvers only (internet gateway best practice: allow only sanctioned DNS servers)" move rulebase security rules ai-dns-sanctioned after ai-block-private | ||||||||
| 6 | ai -> lan | any | any | dns, dns-base | any | reset-both | ||
Why: Plain DNS to any other resolver is reset. best-practice step 3 set rulebase security rules ai-block-dns-other from ai set rulebase security rules ai-block-dns-other to lan set rulebase security rules ai-block-dns-other source any set rulebase security rules ai-block-dns-other destination any set rulebase security rules ai-block-dns-other source-user any set rulebase security rules ai-block-dns-other category any set rulebase security rules ai-block-dns-other application [ dns dns-base ] set rulebase security rules ai-block-dns-other service any set rulebase security rules ai-block-dns-other action reset-both set rulebase security rules ai-block-dns-other log-start no set rulebase security rules ai-block-dns-other log-end yes set rulebase security rules ai-block-dns-other tag ai-zone set rulebase security rules ai-block-dns-other description "Plain DNS to any other resolver is reset" move rulebase security rules ai-block-dns-other after ai-dns-sanctioned | ||||||||
| 7 | ai -> lan | any | any | dns-over-https, dns-over-tls | any | reset-both | ||
Why: Encrypted DNS would hide queries from the firewall. set rulebase security rules ai-block-doh-dot from ai set rulebase security rules ai-block-doh-dot to lan set rulebase security rules ai-block-doh-dot source any set rulebase security rules ai-block-doh-dot destination any set rulebase security rules ai-block-doh-dot source-user any set rulebase security rules ai-block-doh-dot category any set rulebase security rules ai-block-doh-dot application [ dns-over-https dns-over-tls ] set rulebase security rules ai-block-doh-dot service any set rulebase security rules ai-block-doh-dot action reset-both set rulebase security rules ai-block-doh-dot log-start no set rulebase security rules ai-block-doh-dot log-end yes set rulebase security rules ai-block-doh-dot tag ai-zone set rulebase security rules ai-block-doh-dot description "DoH and DoT hide DNS from the firewall; reset" move rulebase security rules ai-block-doh-dot after ai-block-dns-other | ||||||||
| 8 | ai -> lan | any | any | tor, bittorrent, openvpn, ssh, unknown-tcp, unknown-udp, unknown-p2p | any | drop | ||
Why: Applications with no legitimate use here are dropped on any port. best-practice step 3 set rulebase security rules ai-block-evasive from ai set rulebase security rules ai-block-evasive to lan set rulebase security rules ai-block-evasive source any set rulebase security rules ai-block-evasive destination any set rulebase security rules ai-block-evasive source-user any set rulebase security rules ai-block-evasive category any set rulebase security rules ai-block-evasive application [ tor bittorrent openvpn ssh unknown-tcp unknown-udp unknown-p2p ] set rulebase security rules ai-block-evasive service any set rulebase security rules ai-block-evasive action drop set rulebase security rules ai-block-evasive log-start no set rulebase security rules ai-block-evasive log-end yes set rulebase security rules ai-block-evasive tag ai-zone set rulebase security rules ai-block-evasive description "No Tor, BitTorrent, OpenVPN, outbound SSH or unidentified traffic from the AI zone" move rulebase security rules ai-block-evasive after ai-block-doh-dot | ||||||||
| 9 | ai -> lan | g-ai-nodes | NOT g-not-internet | ntp, stun, ping, traceroute | application-default | allowOutbound | ||
Why: Time, overlay connectivity checks (STUN), ping and traceroute on their default ports. set rulebase security rules ai-infra-out from ai set rulebase security rules ai-infra-out to lan set rulebase security rules ai-infra-out source g-ai-nodes set rulebase security rules ai-infra-out destination g-not-internet set rulebase security rules ai-infra-out negate-destination yes set rulebase security rules ai-infra-out source-user any set rulebase security rules ai-infra-out category any set rulebase security rules ai-infra-out application [ ntp stun ping traceroute ] set rulebase security rules ai-infra-out service application-default set rulebase security rules ai-infra-out action allow set rulebase security rules ai-infra-out log-start no set rulebase security rules ai-infra-out log-end yes set rulebase security rules ai-infra-out profile-setting group Outbound set rulebase security rules ai-infra-out tag ai-zone set rulebase security rules ai-infra-out description "NTP, STUN (overlay connectivity checks), ping, traceroute on default ports" move rulebase security rules ai-infra-out after ai-block-evasive | ||||||||
| 10 | ai -> lan | g-ai-nodes | NOT g-not-internet | any | s-tcp-80-443 | allowOutbound | ||
Why: Any App-ID, but only TCP 80/443: port-based on purpose for phase 1 (note under the table); Policy Optimizer narrows it to an application list after a logging period. set rulebase security rules ai-web-out from ai set rulebase security rules ai-web-out to lan set rulebase security rules ai-web-out source g-ai-nodes set rulebase security rules ai-web-out destination g-not-internet set rulebase security rules ai-web-out negate-destination yes set rulebase security rules ai-web-out source-user any set rulebase security rules ai-web-out category any set rulebase security rules ai-web-out application any set rulebase security rules ai-web-out service s-tcp-80-443 set rulebase security rules ai-web-out action allow set rulebase security rules ai-web-out log-start no set rulebase security rules ai-web-out log-end yes set rulebase security rules ai-web-out profile-setting group Outbound set rulebase security rules ai-web-out tag ai-zone set rulebase security rules ai-web-out description "AI nodes to the internet on TCP 80/443 only, Iron Skillet Outbound profiles" move rulebase security rules ai-web-out after ai-infra-out | ||||||||
| 11 | ai -> lan | any | any | any | any | deny | ||
Why: Explicit cleanup for everything else leaving the zone, logged. set rulebase security rules ai-cleanup-deny from ai set rulebase security rules ai-cleanup-deny to lan set rulebase security rules ai-cleanup-deny source any set rulebase security rules ai-cleanup-deny destination any set rulebase security rules ai-cleanup-deny source-user any set rulebase security rules ai-cleanup-deny category any set rulebase security rules ai-cleanup-deny application any set rulebase security rules ai-cleanup-deny service any set rulebase security rules ai-cleanup-deny action deny set rulebase security rules ai-cleanup-deny log-start no set rulebase security rules ai-cleanup-deny log-end yes set rulebase security rules ai-cleanup-deny tag ai-zone set rulebase security rules ai-cleanup-deny description "Cleanup: deny and log anything else leaving the AI zone" move rulebase security rules ai-cleanup-deny after ai-web-out | ||||||||
| 12 | lan -> ai | any | any | any | any | deny | ||
Why: Explicit cleanup for the other direction, logged; management rides the overlay. set rulebase security rules lan-to-ai-deny from lan set rulebase security rules lan-to-ai-deny to ai set rulebase security rules lan-to-ai-deny source any set rulebase security rules lan-to-ai-deny destination any set rulebase security rules lan-to-ai-deny source-user any set rulebase security rules lan-to-ai-deny category any set rulebase security rules lan-to-ai-deny application any set rulebase security rules lan-to-ai-deny service any set rulebase security rules lan-to-ai-deny action deny set rulebase security rules lan-to-ai-deny log-start no set rulebase security rules lan-to-ai-deny log-end yes set rulebase security rules lan-to-ai-deny tag ai-zone set rulebase security rules lan-to-ai-deny description "Cleanup: nothing from the LAN side into the AI zone (management rides the overlay)" move rulebase security rules lan-to-ai-deny after ai-cleanup-deny | ||||||||
| - | intrazone-default | Allow, logged (Iron Skillet override, profile group Inbound): DHCP and ping to the gateway. | allowInbound | |||||
| - | interzone-default | Drop, logged: unchanged. | drop | |||||
| Name | From | To | Source | Destination | Service | Translation |
|---|---|---|---|---|---|---|
| ai-snat-out | ai | lan | n-ai-net | any | any | dynamic-ip-and-port interface-address interface ethernet1/1 |
ssl to a named SaaS application), so an application allow-list breaks unpredictably on frozen content. "Any App-ID, but only TCP 80/443", with the evasive-application drop above it, keeps phase 1 tight; after a logging period Policy Optimizer turns rule 10 into an application list.What the firewall cannot see
Overlay traffic between an AI node and a LAN peer crosses the firewall as encrypted UDP (direct) or as HTTPS to a relay. The firewall allows or drops it as a whole; it cannot filter by port inside the tunnel. The overlay's own policy and the host firewalls on the nodes are the second fence, so rule 3 names two hosts and one port and nothing more.
DNS without a proxy
Clients receive the sanctioned resolvers directly by DHCP option (rule 5 allows DNS to those two addresses only, rule 6 resets plain DNS to anything else, rule 7 resets encrypted DNS). A DNS proxy on the firewall is a later option; it would need its own rule without a blocking anti-spyware profile, because one blocked query would otherwise discard the proxy's upstream session for everyone.
Zone protection
The AI zone gets a profile with reconnaissance blocking (port scans block the source for 300 s, host sweeps alert), spoofed-IP drop, packet-based drops (source routing, malformed and unknown options, overlapping segments, split handshakes, SYN or SYN-ACK with data), TCP timestamp stripping and RED flood limits. The flood numbers are starting values for a handful of clients, meant to cap a runaway agent; they are tuned from the zone's counters after a week.
What would this rulebase do?
A simplified model: first matching rule wins, top to bottom; App-ID is whatever you select (a real firewall identifies it from traffic); user, HIP, schedule and URL category are not modelled; membership of the threat-intel lists is a checkbox. application-default uses one published default port per application. Honest limits of a browser model, not of the design.
The simulator runs locally in your browser and needs JavaScript. The test table below was computed at build time.
Press Evaluate to see which rule the sample policy would apply.
The design's test plan, re-run here
| # | Case | From / to | Source | Destination | App | Proto/port | Expected | Simulated | Agree | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | web on 443 from a reserved node | ai -> lan | 192.0.2.11 | 203.0.113.80 | - | tcp/443 | ai-web-out | ai-web-out | agree | |
| 2 | overlay UDP to a named LAN peer | ai -> lan | 192.0.2.11 | 172.16.0.21 | - | udp/41641 | ai-overlay-lan-direct | ai-overlay-lan-direct | agree | |
| 3 | SSH to the same LAN peer by address | ai -> lan | 192.0.2.11 | 172.16.0.21 | - | tcp/22 | ai-block-private | ai-block-private | agree | |
| 4 | firewall management page | ai -> lan | 192.0.2.11 | 172.16.0.5 | - | tcp/443 | ai-block-private | ai-block-private | agree | |
| 5 | a device on another private network | ai -> lan | 192.0.2.11 | 172.16.37.1 | - | tcp/8080 | ai-block-private | ai-block-private | agree | |
| 6 | shared address space in the clear | ai -> lan | 192.0.2.11 | 100.64.0.1 | - | tcp/22 | ai-block-private | ai-block-private | agree | |
| 7 | DNS to the sanctioned resolver | ai -> lan | 192.0.2.11 | 203.0.113.53 | dns | udp/53 | ai-dns-sanctioned | ai-dns-sanctioned | agree | |
| 8 | DNS to another public resolver | ai -> lan | 192.0.2.11 | 203.0.113.99 | dns | udp/53 | ai-block-dns-other | ai-block-dns-other | agree | |
| 9 | outbound SSH | ai -> lan | 192.0.2.11 | 203.0.113.80 | ssh | tcp/22 | ai-block-evasive | ai-block-evasive | agree | |
| 10 | NTP | ai -> lan | 192.0.2.11 | 203.0.113.80 | ntp | udp/123 | ai-infra-out | ai-infra-out | agree | |
| 11 | a non-standard web port | ai -> lan | 192.0.2.11 | 203.0.113.80 | - | tcp/8443 | ai-cleanup-deny | ai-cleanup-deny | agree | |
| 12 | an unreserved client | ai -> lan | 192.0.2.150 | 203.0.113.80 | - | tcp/443 | ai-cleanup-deny | ai-cleanup-deny | agree | |
| 13 | LAN into the AI zone | lan -> ai | 172.16.0.21 | 192.0.2.12 | - | tcp/22 | lan-to-ai-deny | lan-to-ai-deny | agree | |
| 14 | source NAT for the web case (NAT) | ai -> lan | 192.0.2.11 | 203.0.113.80 | - | tcp/443 | ai-snat-out | ai-snat-out | agree |
14 of 14 cases agree with the design (computed at build time).
| # | Check | Expected |
|---|---|---|
| 1 | addressing | the node holds its reserved address with the AI gateway as default route |
| 2 | web, first public host | HTTP 200 |
| 3 | web, second public host | HTTP 200 |
| 4 | a LAN service by address | timeout |
| 5 | the firewall management page by address | timeout |
| 6 | DNS via the sanctioned resolver, then via another public resolver | an answer, then no answer |
| 7 | time sync status | a server and an offset |
| 8 | overlay status | both LAN peers shown as direct |
| 9 | overlay ping to the lab server | replies via the direct path |
| 10 | overlay connectivity check | UDP works; the mapping varies by destination behind dynamic NAT (expected) |
| 11 | SSH to the lab server over the overlay | refused or timeout (overlay policy) |
| 12 | outbound SSH to a public host | no connection (dropped by the evasive-apps rule) |
Set-command checker
The lab's offline checker, ported line for line: a set line passes when it matches a path of the PAN-OS 11.1 configure hierarchy (keywords and enumerated values; free-text values match anything), a delete line when the deleted node exists as a set path, a move line when it follows the documented move syntax. Paste or edit lines; press Check or Ctrl+Enter.
The checker runs locally in your browser and needs JavaScript (nothing is uploaded). Table 5 lists the example lines with the verdict each would get.
| Line | Verdict | Why |
|---|---|---|
| set zone ai network layer3 ethernet1/2 | OK | a line of the sample file |
| set address h-ai-node-a ip-netmask 192.0.2.11/32 | OK | a line of the sample file |
| set address-group g-ai-nodes static [ h-ai-node-a h-ai-node-b ] | OK | a line of the sample file |
| set service s-tcp-80-443 protocol tcp port 80,443 | OK | a line of the sample file |
| set rulebase security rules ai-web-out action allow | OK | a line of the sample file |
| set rulebase nat rules ai-snat-out source-translation dynamic-ip-and-port interface-address interface ethernet1/1 | OK | a line of the sample file |
| set network dhcp interface ethernet1/2 server reserved 192.0.2.11 mac 00:00:5e:00:53:11 | OK | a line of the sample file |
| move rulebase security rules ai-web-out after ai-infra-out | OK | a line of the sample file |
| set rulebase security rulez ai-web-out action allow | FAIL | typo in a keyword (rulez) |
| set rulebase security rules ai-web-out action permit | FAIL | permit is not a PAN-OS action (deny, allow, drop, reset-...) |
| set rulebase security rules ai-web-out log-end maybe | FAIL | log-end takes yes or no |
| move rulebase security rules ai-web-out above ai-infra-out | FAIL | move takes top, bottom, before or after |
| delete rulebase security rulez ai-web-out | FAIL | the delete path does not exist |
| set deviceconfig system hostname fw-lab | OUTSIDE | a real command family that this demo does not ship; the lab tool checks it |
Not checked by this tool: free-text values (App-ID names, object and list names, descriptions), the ranges of addresses and numbers (a mask of /99 or a port of 99999 passes where the path takes a value), balanced quotes, and policy intent. A line that passes here is syntactically a PAN-OS 11.1 path; whether it is the right line is the design's job, and the firewall's own validate full stays the real test.
Lines from command families this demo does not ship are reported as OUTSIDE, not as failures; the lab tool checks all 9,719 paths.
About this demo
- hierarchy
- Derived from Palo Alto Networks' public PAN-OS 11.1 Configure CLI Command Hierarchy, read October 2026: 9,719
setpaths on the page. This demo ships the 25 command families this design uses (2,561 paths, keywords and enumerated values only, as a trie) so the checker works offline here; the lab tool reads the full page at run time and ships nothing. Families here: set address (9), set address-group (8), set application (69), set application-filter (22), set external-list (72), set import network interface (1), set network dhcp interface (51), set network dns-proxy (32), set network interface ethernet (493), set network profiles interface-management-profile (15), set network profiles zone-protection-profile (807), set network qos interface (32), set network virtual-router (750), set network virtual-wire (9), set profile-group (9), set profiles url-filtering (38), set rulebase application-override rules (16), set rulebase default-security-rules rules (19), set rulebase nat rules (48), set rulebase qos rules (38), set rulebase security rules (43), set service (21), set service-group (4), set tag (4), set zone (21). For the OUTSIDE verdict the file also lists the names (first two to four keywords) of all 407 command families on the page, without their paths. - sample file
- 350 configuration lines, generated from the staged change file with every address, MAC, host and object name replaced by a documentation placeholder and every description rewritten; the build re-checks it against the full hierarchy (expected: 0 failures) and against the shipped subset (same), and a node harness proves the JS verdicts equal the Python tool's over the sample, the examples and 58 generated mutations (typos, enum swaps, truncations, extra tokens, unclosed or stray brackets, stray spaces).
- test plan
- The 14 firewall-side cases follow the design's own test plan (test security-policy-match on the real firewall, after a commit); here they run through the simulator above. The 12 node-side checks are listed, not run.
- what is not here
- Management-plane settings, accounts, exposure or patch details, the overlay policy, the cutover and rollback steps, and anything that names the lab's networks, devices or people.
- trademarks
- PAN-OS, App-ID and Palo Alto Networks are trademarks of Palo Alto Networks, Inc., used here to describe the product. This is a personal demo, not affiliated with or endorsed by Palo Alto Networks.
- downloads
- sample.set (the sanitized sample)
- rules.json
- tests.json
- hierarchy.json (the shipped subset, with provenance)
- links
- The project page (what was built, how AI was used, status and limits) and the portfolio.