Jesse A. Green / notebook

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.

Zones of the AI-zone design Internet, then the ISP router, then the lab firewall. Port 1 is zone lan with two named LAN peers. Port 2 is zone ai: one access point and two AI nodes, dashed because the zone is designed and not committed. Allowed flows out of the AI zone: web on TCP 80 and 443, DNS to the sanctioned resolvers, NTP, STUN, ping, traceroute, and the overlay's UDP port to the two LAN peers. Struck-through flows: anything private from the AI zone is dropped; anything from the LAN into the AI zone is denied. Internet zone lan (port 1) ISP routerupstream LAN, NAT LAN peerslab server, desktop Lab firewallPAN-OS 11.1port 1: lan, static addressport 2: ai, gateway + DHCPNAT ai -> port-1 addressports 3-8: reserved zone ai (port 2): designed, not committed Access pointAP mode, one SSID AI node Areserved AI node Breserved future nodereserved web 80/443, sanctioned DNS,NTP, STUN, ping, traceroute anything private:dropped overlay UDP tothe 2 LAN peers lan to ai:denied

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
Figure 1Zones and flows of phase 1. Later zones (IoT, guest, cameras) are reserved on the remaining ports and are not part of this sample file. Placeholders: AI network 192.0.2.0/24 (RFC 5737 TEST-NET-1); LAN side 172.16.0.0/24 (an RFC 1918 placeholder block); internet hosts and resolvers 203.0.113.0/24 (RFC 5737 TEST-NET-3); MACs 00:00:5e:00:53:xx (RFC 7042 documentation MACs).

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.

Table 1. The rulebase in the order the move lines enforce. Click a name for why the rule is there (with its source) and the exact sanitized set lines that build it. Action shows the profile group under it; the Simulated column fills when you press Evaluate below.
#NameZonesSourceDestinationApplicationServiceActionSimulated
1any -> anyany3 predefined threat-intel listsanyanydeny
2any -> any3 predefined threat-intel listsanyanyanydeny
3ai -> lang-ai-nodesg-overlay-lan-peersanys-udp-overlayallowOutbound
4ai -> lananyg-not-internetanyanydrop
5ai -> lang-ai-nodesg-dns-sanctioneddns, dns-baseapplication-defaultallowOutbound
6ai -> lananyanydns, dns-baseanyreset-both
7ai -> lananyanydns-over-https, dns-over-tlsanyreset-both
8ai -> lananyanytor, bittorrent, openvpn, ssh, unknown-tcp, unknown-udp, unknown-p2panydrop
9ai -> lang-ai-nodesNOT g-not-internetntp, stun, ping, tracerouteapplication-defaultallowOutbound
10ai -> lang-ai-nodesNOT g-not-internetanys-tcp-80-443allowOutbound
11ai -> lananyanyanyanydeny
12lan -> aianyanyanyanydeny
-intrazone-defaultAllow, logged (Iron Skillet override, profile group Inbound): DHCP and ping to the gateway.allowInbound
-interzone-defaultDrop, logged: unchanged.drop
Table 2. The one NAT rule.
NameFromToSourceDestinationServiceTranslation
ai-snat-outailann-ai-netanyanydynamic-ip-and-port interface-address interface ethernet1/1
Why rule 10 is port-based. App-ID re-matches a session when the identification shifts (for example from 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.

first match wins; the trace lands in Table 1

Press Evaluate to see which rule the sample policy would apply.

The design's test plan, re-run here

Table 3. The design's firewall-side test plan: 13 policy-match cases and 1 NAT case, with placeholder addresses. Expected = the rule the design names; Simulated = what the model here computes. The build ran these in Python and in the JS; the browser re-runs them on load.
#CaseFrom / toSourceDestinationAppProto/portExpectedSimulatedAgree
1web on 443 from a reserved nodeai -> lan192.0.2.11203.0.113.80-tcp/443ai-web-outai-web-outagree
2overlay UDP to a named LAN peerai -> lan192.0.2.11172.16.0.21-udp/41641ai-overlay-lan-directai-overlay-lan-directagree
3SSH to the same LAN peer by addressai -> lan192.0.2.11172.16.0.21-tcp/22ai-block-privateai-block-privateagree
4firewall management pageai -> lan192.0.2.11172.16.0.5-tcp/443ai-block-privateai-block-privateagree
5a device on another private networkai -> lan192.0.2.11172.16.37.1-tcp/8080ai-block-privateai-block-privateagree
6shared address space in the clearai -> lan192.0.2.11100.64.0.1-tcp/22ai-block-privateai-block-privateagree
7DNS to the sanctioned resolverai -> lan192.0.2.11203.0.113.53dnsudp/53ai-dns-sanctionedai-dns-sanctionedagree
8DNS to another public resolverai -> lan192.0.2.11203.0.113.99dnsudp/53ai-block-dns-otherai-block-dns-otheragree
9outbound SSHai -> lan192.0.2.11203.0.113.80sshtcp/22ai-block-evasiveai-block-evasiveagree
10NTPai -> lan192.0.2.11203.0.113.80ntpudp/123ai-infra-outai-infra-outagree
11a non-standard web portai -> lan192.0.2.11203.0.113.80-tcp/8443ai-cleanup-denyai-cleanup-denyagree
12an unreserved clientai -> lan192.0.2.150203.0.113.80-tcp/443ai-cleanup-denyai-cleanup-denyagree
13LAN into the AI zonelan -> ai172.16.0.21192.0.2.12-tcp/22lan-to-ai-denylan-to-ai-denyagree
14source NAT for the web case (NAT)ai -> lan192.0.2.11203.0.113.80-tcp/443ai-snat-outai-snat-outagree

14 of 14 cases agree with the design (computed at build time).

Table 4. The 12 node-side checks (run from each AI node after cutover; shown, not run: there is nothing here to run them against).
#CheckExpected
1addressingthe node holds its reserved address with the AI gateway as default route
2web, first public hostHTTP 200
3web, second public hostHTTP 200
4a LAN service by addresstimeout
5the firewall management page by addresstimeout
6DNS via the sanctioned resolver, then via another public resolveran answer, then no answer
7time sync statusa server and an offset
8overlay statusboth LAN peers shown as direct
9overlay ping to the lab serverreplies via the direct path
10overlay connectivity checkUDP works; the mapping varies by destination behind dynamic NAT (expected)
11SSH to the lab server over the overlayrefused or timeout (overlay policy)
12outbound SSH to a public hostno 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.

    Table 5. The pre-filled example lines and the verdict the checker gives each (verified at build time against the lab tool).
    LineVerdictWhy
    set zone ai network layer3 ethernet1/2OKa line of the sample file
    set address h-ai-node-a ip-netmask 192.0.2.11/32OKa line of the sample file
    set address-group g-ai-nodes static [ h-ai-node-a h-ai-node-b ]OKa line of the sample file
    set service s-tcp-80-443 protocol tcp port 80,443OKa line of the sample file
    set rulebase security rules ai-web-out action allowOKa line of the sample file
    set rulebase nat rules ai-snat-out source-translation dynamic-ip-and-port interface-address interface ethernet1/1OKa line of the sample file
    set network dhcp interface ethernet1/2 server reserved 192.0.2.11 mac 00:00:5e:00:53:11OKa line of the sample file
    move rulebase security rules ai-web-out after ai-infra-outOKa line of the sample file
    set rulebase security rulez ai-web-out action allowFAILtypo in a keyword (rulez)
    set rulebase security rules ai-web-out action permitFAILpermit is not a PAN-OS action (deny, allow, drop, reset-...)
    set rulebase security rules ai-web-out log-end maybeFAILlog-end takes yes or no
    move rulebase security rules ai-web-out above ai-infra-outFAILmove takes top, bottom, before or after
    delete rulebase security rulez ai-web-outFAILthe delete path does not exist
    set deviceconfig system hostname fw-labOUTSIDEa 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 set paths 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
    links
    The project page (what was built, how AI was used, status and limits) and the portfolio.