Parse PAN-OS and Panorama XML or set-format exports into the shared firewall schema. Use when input contains vsys, device-group, security rulebase, address-group, application-default, security-profile-group, set deviceconfig, or XML entry/member elements, including audit, conversion, diff, summary, and explanation tasks.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Parse PAN-OS and Panorama XML or set-format exports into the shared firewall schema. Use when input contains vsys, device-group, security rulebase, address-group, application-default, security-profile-group, set deviceconfig, or XML entry/member elements, including audit, conversion, diff, summary, and explanation tasks.
Use this skill to parse Palo Alto PAN-OS firewall or Panorama configuration exports into the shared vendor-neutral firewall intermediate schema. It primarily targets XML exports and also covers flat set-style output when available, including vsys, device-groups, shared objects, zones, address/service/application objects, security rules, NAT rules, routes, profiles, tags, User-ID references, and system settings.
Panorama inheritance and rulebase placement are critical. Preserve shared/device-group/vsys context, distinguish pre-rules and post-rules, and record unresolved inherited references rather than flattening them silently.
Scope and routing
Use only for PAN-OS or Panorama XML and set-format syntax. Hand off ASA/FTD access-list, nameif, or object network input to parsing-cisco-configs, FortiOS blocks to parsing-fortinet-configs, and Junos hierarchy or set security to parsing-srx-configs. Verify production-bound results against current device documentation and output. Downstream consumers are the audit, conversion, and diff skills.
Input Format
PAN-OS configs come in two formats. Auto-detect which one:
XML format — show running-config, running-config.xml export, or Panorama config
Set format — show config flat output with set <path> <value> lines
Detection: Check if input starts with < or contains XML tags → XML mode. Lines starting with set → set-format mode.
Set-format tokenization: Handle double-quoted strings (preserve as single tokens), [ ] bracket list notation (expand to multiple values), and inline # comments. Example: set deviceconfig system hostname fw1 maps to XML path deviceconfig.system.hostname = fw1.
XML Structure Conventions
PAN-OS XML uses two critical element patterns:
<entry name="..."> — Named objects. Always treat as arrays even when single.
Use findVsysEntries() logic: try each path, collect all vsys entries.
Extraction Pipeline
1. Zones
Path: zone.entry[]
Extract: zone name (from @name attribute), zone type (from child element: network.layer3,
network.layer2, network.virtual-wire, network.tap), interfaces list.
2. Address Objects
Path: address.entry[]
Types — detect by which child element exists:
<sctp><port> → protocol: "sctp" — platform-conditional: valid only on PAN-OS 9.0+ platforms with SCTP security enabled (warn: limited support)
PAN-OS service objects are TCP/UDP (and conditionally SCTP) port objects only. ICMP matching is application-based (the ping/icmp App-IDs), not a service-object protocol. If any other protocol child element appears, capture its XML in residual_raw and add a warning.
Also extract <description> from service objects.
5. Service Groups
Path: service-group.entry[]
Extract <members><member> list.
Also extract <description> from service groups.
6. Applications (Custom)
Path: application.entry[]
Extract: name, description, default port from <default><port><member>.
Port format: tcp/80,443 or udp/53 — parse protocol and port range.
services — <service><member> list (often "application-default")
action — <action> child element name: allow, deny, drop, reset-client, reset-server, reset-both
Preserve drop as action: "drop" (distinct from deny), consistent with references/parsing-patterns.md and the schema. Do not collapse drop into deny. Add a conversion warning only for target platforms that cannot distinguish a silent drop from an explicit deny.
log_start — <log-start>yes</log-start>
log_end — <log-end>yes</log-end>
disabled — <disabled>yes</disabled>
description — <description> text
tags — <tag><member> list
schedule — <schedule> text
source_users — <source-user><member> list (User-ID)
Warn if non-"any" values found: User-ID has no direct equivalent on most platforms
url_categories — <category><member> list
Security profiles — check <profile-setting>. Map PAN-OS profile names to the
security_profiles schema keys (left = PAN-OS XML element, right = schema key):
<group><member> → profile_group name, then resolve from profile-group definitions
<profiles> → individual profiles:
<virus><member> → virus
<spyware><member> → anti-spyware
<vulnerability><member> → idp (PAN-OS calls this Vulnerability Protection / IPS; the schema key is idp)
<url-filtering><member> → url-filtering
<file-blocking><member> → file-blocking
<wildfire-analysis><member> → wildfire
<data-filtering><member> → dlp
9. NAT Rules
Path: rulebase.nat.rules.entry[]
For each rule:
Determine NAT type from <source-translation> and/or <destination-translation> presence
Source NAT:<source-translation> with <dynamic-ip-and-port> (interface or translated-address)
or <static-ip> with <translated-address>
Destination NAT:<destination-translation> with <translated-address> and optional <translated-port>
Both: has both source and destination translation → type: "source-and-destination"
Aggregate-ethernet (ae1): LAG with layer3 IP, MTU, sub-units
Loopback (loopback.N): IP and description
VLAN (vlan.N): IP and VLAN tag
Tunnel (tunnel.N): IP for VPN binding
Derive interface type from name: ae*=lag, loopback*=loopback, tunnel*=tunnel, vlan*=vlan.
Back-populate lag_members on aggregate interfaces after parsing all interfaces.
Subinterface zone inheritance: if a subinterface has no zone but its parent does, inherit the parent's zone.
Path: mgt-config.users.entry[]
Extract: username, SSH public key (ssh-public-key or older public-key), role from permissions (superuser→super-admin, devicereader→read-only, deviceadmin→admin).
Only migrate users with SSH keys; warn about others.
IKE crypto profiles: encryption, integrity, DH groups, lifetime
IPsec crypto profiles: ESP encryption/authentication, DH group (PFS), lifetime
IKE gateways: version (IKEv1/v2), auth method (PSK or certificate), PSK presence (mask the value as "****"), local/peer address, local/peer ID, crypto profile reference, local cert + CA profile
Flag weak algorithms (DES/3DES, MD5, DH group ≤ 5)
Zone protection:network.profiles.zone-protection-profile.entry[]
Syslog:shared.log-settings.syslog.entry[]
Virtual wire:network.virtual-wire.entry[]
16. Application Resolution (L7 → Canonical)
PAN-OS has the richest L7 application model of any firewall vendor. Security policies use
<application><member> to match traffic by application signature, independent of port.
Resolution steps for each application name in a policy:
Service object/group check: If the name matches a service object or service group → promote
to the services array (PAN-OS sometimes places port-based matches in the application field)
Application group check: If the name matches an application-group.entry[] → add to policy's
app_groups array
Custom application check: If the name matches a application.entry[] (custom app) → keep it
as an L7 application reference under applications/apps. Capture its <default><port> definition
as app metadata / a conversion hint (e.g. default_port), but do NOT replace the application with a
service object — a custom App-ID remains an L7 application.
Cross-vendor canonical resolution: Resolve through the app mapping table
PAN-OS application names to canonical:
PAN-OS Name
Canonical App
Category
ssl
https
web
web-browsing
http
web
ssh
ssh
remote-access
ms-rdp
rdp
remote-access
dns
dns
network-mgmt
smtp
smtp
email
ntp
ntp
network-mgmt
snmp
snmp
network-mgmt
ftp
ftp
file-transfer
tftp
tftp
file-transfer
sip
sip
voip
ldap
ldap
auth
kerberos
kerberos
auth
smb
smb
file-transfer
ms-sql-s
mssql
database
mysql
mysql
database
postgresql
postgresql
database
ms-teams
ms-teams
collaboration
zoom
zoom
collaboration
webex
webex
collaboration
slack
slack
collaboration
youtube
youtube
streaming
netflix
netflix
streaming
office365-enterprise-access
ms-office365
collaboration
google-drive-web
google-drive
cloud-storage
dropbox
dropbox
cloud-storage
application-default service: When a policy sets <service><member>application-default</member>,
PAN-OS uses each application's built-in default port. For the IR, keep services: ["application-default"]
and rely on the apps array for resolution. During conversion to port-based platforms, decompose
each resolved app's default port into explicit service matches.
On policy output: For each resolved app, populate apps array:
{ vendor_name: "ssl", canonical: "https", confidence: 1.0, category: "web" }
Custom applications (application.entry[]): Extract the <default><port><member> list.
Format is tcp/80,443 or udp/53 — parse protocol and port range and attach it as app metadata
(e.g. a default_port field / conversion hint) on the custom app's entry under applications/apps.
Keep the custom app as an L7 application reference; do NOT create a service object or move it into the
policy's services array. Only decompose the default port into explicit service matches during target
conversion when the target platform requires it. Set confidence: 0.9 since custom apps may not have
an exact canonical equivalent.
Unresolvable apps: PAN-OS has 3000+ built-in application signatures. Many are vendor-specific
(e.g., palo-alto-networks, fortinet). For unknown apps, set confidence: 0.0, preserve the
vendor_name, and warn. These will go to residual during conversion.
If a member is itself an application group → recurse
If a member is a custom application → extract its port definition
Store in application_groups with canonical member names.
Mixed groups: If a group contains both L7 apps and port-based services, split them:
L7 apps → application_groups, port-based → service_groups.
17. Multi-vsys
If multiple vsys entries found:
Parse each independently
Tag all policies and objects with _vsys: "vsys1" etc.
Merge into flat arrays
Re-index _rule_index sequentially
18. Residual Config Capture
Capture unhandled configuration sections. In XML mode, serialize unhandled elements back to XML strings. Categorize into: VPN Tunnels, IKE, IPsec Crypto, QoS, DNS Proxy, Shared Objects, PKI/Certificates, Security Profiles, Custom Applications, Policy-Based Forwarding, Panorama Config, Other. Store in residual_raw.
19. Implicit Rules
After parsing all explicit policies, append per-context:
Implicit: Intra-zone Allow — per zone, action: "allow", _implicit: true
(for each zone, src_zones = dst_zones = [zone_name])
Implicit-rule name values (e.g. "default-deny", "Implicit: Default Deny") are free-form labels; consumers must match implicit rules on _implicit: true, never on the name.
Output Format
Present results in the intermediate schema format documented in references/intermediate-schema.md.
Note: schema sections not yet populated by this pipeline (e.g., security_profile_objects, routing_contexts) are emitted empty ([]/{}); any unhandled source constructs are captured in residual_raw rather than dropped.
Full intermediate-schema emission is optional for single live-device work. The complete JSON schema exists primarily for cross-vendor conversion and multi-config diffing. When interpreting or auditing a single live device pulled via the XML API for an ops/audit task, it is fine to reason directly from the XML config and skip full schema emission — extract the sections relevant to the question. Emit the full schema when the parse will feed firewall-config-conversion, firewall-config-diff, or another config for comparison.
Parser Quality Gates
Before returning a parse, run these common quality gates and include the results in the response:
Format and scope detection — report detected vendor, platform family, config format, version clues, virtual context names (VDOM/vsys/logical-system/routing-instance), and whether input appears complete or partial.
Schema conformance — emit the vendor-neutral JSON sections defined in references/intermediate-schema.md; use empty arrays/objects for absent sections rather than omitting expected top-level keys.
Object counts — summarize counts for zones, interfaces, address objects/groups, service/application objects/groups, policies, NAT rules, routes, VPNs, HA, admin users, and residual blocks.
Reference resolution — list unresolved object, service/application, zone/interface, profile, route, VPN, and NAT references with source rule/context where possible.
Ordering preservation — preserve security policy order, NAT order, and route order when relevant. For Panorama, encode the full merged evaluation order (shared → device-group pre-rulebase → local/vsys rulebase → device-group post-rulebase, with nested device-group inheritance) using _rule_index. The schema defines only _rule_index and _vsys for PAN-OS context, so record device-group / pre-vs-post origin in metadata.warnings or residual_raw rather than inventing a context field.
State preservation — preserve disabled/inactive objects and rules, comments/descriptions, tags, schedules/time-ranges, negation flags, logging settings, and profile attachments.
Residual capture — put unsupported or ambiguous source lines/blocks into residual_raw with enough context for manual review. Do not silently drop unknown syntax.
Warnings and assumptions — populate metadata.warnings with parser limitations, partial-input assumptions, ambiguous conversions, and version-specific caveats.
Conversion readiness — if the user asks for migration/conversion, explicitly separate parsed facts from proposed target-platform design choices and call out non-isomorphic features.
A high-quality parse is not just valid JSON: it must make uncertainty visible. Prefer a complete parse with warnings and residuals over a clean-looking parse that hides unsupported constructs.
Analysis Checks
After extraction, run these checks and report findings:
Unused objects — address/service objects not referenced by any policy
Shadowed policies — rules fully covered by earlier rules
Overly permissive — rules with any/any or negate patterns covering everything
Missing logging — permit rules without log-end enabled
Disabled policies — rules with <disabled>yes</disabled>
Duplicate objects — same value, different names
Empty groups — groups with no members
Dynamic groups — flag for manual review (no static equivalent)
User-ID dependencies — rules relying on source-user for access control
URL category dependencies — rules using URL categories for access control
Reference Files
references/config-format.md — PAN-OS XML structure reference
references/fixture-expected-output.json — Expected high-level intermediate-schema output for the minimal fixture
Secret Handling
Never emit secrets raw. IKE/VPN pre-shared keys, routing-protocol authentication keys (BGP/OSPF), and user password hashes must be masked as "****" (or reduced to a presence flag) with a metadata.warnings entry noting the redaction — matching the shared-schema convention ("psk": "****").
Common Pitfalls
Do not collapse Panorama shared, device-group, and vsys scopes without preserving source context.
Preserve pre-rulebase vs post-rulebase order; rule placement changes behavior.
application-default is not a normal service object. Represent it explicitly and warn during cross-vendor conversion.
Application, service, URL category, tag, and profile references can look similar; resolve each against the correct object tree.
Disabled rules, negation, User-ID fields, and dynamic address groups are easy to lose; capture them explicitly or warn.
Verification Checklist
Input vendor/platform and config format were detected correctly
All major object counts are reported: zones, interfaces, addresses, services/applications, policies, NAT, routes, VPN, HA, and system settings
Output conforms to references/intermediate-schema.md
Disabled/inactive rules and objects are preserved with explicit state
Unresolved references, unsupported blocks, and parser assumptions are listed in metadata.warnings and/or residual_raw
Rule order and NAT order are preserved with _rule_index or equivalent ordering metadata
Cross-vendor conversion caveats are called out before suggesting target-platform config
No raw secrets in output — PSKs masked as "****", routing-protocol passwords/keys reduced to presence flags with warnings
