Parse Juniper SRX and Junos display-set or hierarchical configurations into the shared firewall schema. Use when input contains set security, zones, policies, address-book, from-zone, to-zone, NAT rule-set, chassis cluster, logical-systems, or routing-instances, including audit, conversion, diff, summary, and explanation tasks.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Parse Juniper SRX and Junos display-set or hierarchical configurations into the shared firewall schema. Use when input contains set security, zones, policies, address-book, from-zone, to-zone, NAT rule-set, chassis cluster, logical-systems, or routing-instances, including audit, conversion, diff, summary, and explanation tasks.
Use this skill to parse Juniper SRX / Junos firewall configurations into the shared vendor-neutral firewall intermediate schema. It supports both show configuration | display set lines and hierarchical curly-brace configuration, including zones, address books, applications, security policies, NAT, logical-systems, routing-instances, interfaces, routing protocols, VPN, chassis cluster, and system settings.
Scope and routing
Use only for Juniper SRX or Junos hierarchy and display-set syntax. Hand off ASA/FTD access-list, nameif, or object network input to parsing-cisco-configs, FortiOS blocks to parsing-fortinet-configs, and PAN-OS XML or set deviceconfig to parsing-palo-configs. Verify production-bound results against current device documentation and output. Downstream consumers are the audit, conversion, and diff skills.
Input Format Detection
SRX configs come in two formats. Detect which one:
Set commands — Lines starting with set or deactivate . Example:
set security zones security-zone trust interfaces ge-0/0/0.0
set security policies from-zone trust to-zone untrust policy allow-web match source-address any
Hierarchical (curly-brace) — Nested blocks with { } and ; terminators. Example:
Detection heuristic: Check the first 2000 characters for known top-level stanza names followed by { (e.g., system {, security {, interfaces {, routing-options {). If found, treat as hierarchical. Otherwise treat as set-command format.
Hierarchical to Set Conversion
If hierarchical format is detected, mentally convert to flat set commands before parsing:
Track the current path as you descend into { } blocks
Each leaf value terminated by ; becomes: set <path> <value>
Handle inactive: prefix → convert to deactivate <path>
Note: inactive: (hierarchical format) and deactivate (set format) are equivalent. In hierarchical parsing, strip inactive: and set enabled: false on the affected object. Handle the re-parse: strip the prefix, rebuild as a normal set line, re-tokenize to extract the target object name.
Handle bracket lists [val1 val2] → expand to one set command per value
Handle quoted strings as single tokens
Handle backslash escapes inside quoted strings
Strip block comments /* ... */
Hierarchical-to-set normalization: After conversion, normalize these impedance mismatches:
range-address X to range-high Y → range-address X to Y
address NAME ip-prefix CIDR → address NAME CIDR
then static-nat prefix name CIDR → then static-nat prefix CIDR
then source-nat pool pool-name NAME → then source-nat pool NAME
then destination-nat pool pool-name NAME → then destination-nat pool NAME
then destination-nat ip addr X → then destination-nat ip X
Extraction Pipeline
Parse the following sections in order. For each, read the reference files as needed.
1. Zones
Path: security.zones.security-zone.<name>
Extract: zone name, interfaces list, description, host-inbound-traffic services/protocols
1b. Interfaces
Path: interfaces.<name> with units at interfaces.<name>.unit.<id>
LAG membership: ether-options 802.3ad <ae-name> → set lag_parent
LAG master: aggregated-ether-options lacp config
Interface type derivation:ae*=lag, lo*=loopback, st0/gr-/ip-/lt-=tunnel, fxp0/fxp1/me0/em0/em1=management.
Management interface zone exclusion: Remove management interfaces (fxp0, me0, em0, etc.) from security zones with a warning.
Unit-0 normalization: When resolving zone membership, normalize .0 suffixed names (e.g., ge-0/0/0.0 → ge-0/0/0) for matching.
Cluster interface exclusion: Skip only true fabric/control interfaces (fab*) and management (fxp*) from security zones with a warning. reth* (redundant Ethernet) and reth*.<unit> are normal dataplane interfaces bound to security zones in a chassis cluster — parse them as usable zone interfaces, not as excluded cluster interfaces.
After all interfaces parsed, back-populate lag_members on ae interfaces.
2. Address Objects
Path: security.address-book.global.address.<name>
Types to handle:
ip-prefix (e.g., 10.0.0.0/24) — type: "subnet"
dns-name — type: "fqdn"
range-address with to — type: "range", value: "start-end"
wildcard-address — type: "wildcard"
Plain IP with /32 — type: "host"
ip-prefix <cidr> / ipv6-prefix <cidr> — explicit keywords in hierarchical format (normalize away during hierarchical-to-set conversion)
Zone-attached address books — two valid forms:
Named books with zone attachment:security.address-book.<book-name>.address.<name> plus security.address-book.<book-name>.attach.zone.<zone>. The book name is arbitrary (operators often name it after the zone) — derive zone scope from the attach zone statement, never from the book name.
Legacy zone-local books:security.zones.security-zone.<zone>.address-book.address.<name> (older configs; a zone cannot use both forms at once).
Migrate both forms to global scope with a warning.
Auto-detect IP version (v4 vs v6) from the value.
3. Address Groups
Path: security.address-book.global.address-set.<name>
Extract members from address and nested address-set references.
4. Service Objects (Applications)
Path: applications.application.<name>
Extract: protocol (from protocol field), destination port (from destination-port),
source port if present, ICMP type/code, inactivity-timeout, description.
Map protocol values: 6 or tcp → TCP, 17 or udp → UDP, 1 or icmp → ICMP.
5. Application Mapping (L7 → Canonical)
JunOS uses predefined junos-* applications that are matched by name in security policies.
These are L7-aware on SRX and must be resolved to canonical names for cross-vendor conversion.
Names verified against show configuration groups junos-defaults applications on
Junos 24.4. Note there is no predefined junos-snmp, junos-snmptrap,
junos-mysql, junos-ike-nat-t, junos-icmpv6-all, or junos-ping6 — SNMP and
MySQL matching require custom applications application definitions (extract
those as custom apps); the NAT-T/ICMPv6 predefined names are junos-ike-nat,
junos-icmp6-all, and junos-pingv6.
Resolution in policies: When match application lists a predefined app:
The services array keeps application-default or explicit port references separately
Custom applications (applications.application.<name>): These are user-defined with explicit
protocol and port. Extract as service objects AND attempt canonical resolution from protocol+port.
If the port matches a known app, set confidence: 0.9.
Unresolvable apps: For any application match or custom apps without a canonical mapping,
set confidence: 0.0, preserve the vendor_name, and warn.
5b. Service Groups (Application Sets)
Path: applications.application-set.<name>
Extract member applications and nested application-sets.
Application-Set vs Application-Group distinction:
Determine member types: for each member, check if it is a predefined junos-* L7 app or a
user-defined port-based application
Application-sets containing all L7/predefined apps → promote to application_groups with
canonical member names
Sets containing user-defined port-based apps → keep as service_groups
Resolve each L7 member from JunOS name to canonical before storing in application_groups.
6. Security Policies
Path: security.policies.from-zone.<src>.to-zone.<dst>.policy.<name>
Also: security.policies.global.policy.<name> (global policies, src/dst zones = ["any"])
For each policy extract:
name and description
src_zones / dst_zones — from the path (or ["any"] for global)
src_addresses / dst_addresses — from match source-address / match destination-address
applications — from match application
action — permit → "allow", deny → "deny", reject → "reset-both" (the schema's reject-family value). Note: SRX reject notifies the source only — TCP RST to the client, ICMP unreachable for other protocols — not both sides; emit an info warning so conversions do not overstate reset-both semantics on the target platform.
log_start — true if then log session-init
log_end — true if then log session-close
security_profiles — extract from then permit application-services:
utm-policy → profile_group
idp-policy → IDP profile
ssl-proxy → SSL proxy profile
disabled — true if deactivate prefix on the policy path
schedule — from scheduler-name
source_users — from match source-identity
Handle then count and then permit firewall-authentication as no-ops (do not misinterpret as action modifiers)
Extract: type, src/dst zones (from rule-set from/to), match addresses,
translated source/destination/port.
Source NAT specifics:
then source-nat interface → translate to egress interface
then source-nat pool <poolname> → translate to named pool (emit as pool:<name>)
Destination NAT specifics:
destination-port <port> → original service match
then destination-nat pool <poolname> → translated destination from pool
Port translation lives on the pool object, not the rule: security.nat.destination.pool.<name> carries address <ip/prefix> and optional port <port> — resolve translated address AND port from the referenced pool definition (... pool <name> port <port> on the rule is not valid Junos)
Handle hierarchical ip addr <ip> form for inline destination translation
Static NAT specifics:
then static-nat prefix <cidr> → bidirectional static translation
8. Schedules
Path: schedulers.scheduler.<name>
Extract: name, type (daily-except/daily), start-date, stop-date, days of week, time ranges.
9. Routing
Static routes (IPv4):routing-options.static.route.<prefix> with next-hop, qualified-next-hop (floating statics), or discard (null routes)
Static routes (IPv6):routing-options.rib.inet6.0.static.route.<prefix> — same structure
OSPFv3:protocols.ospf3 — same structure as OSPF via ospf3 instances
Multicast (presence flag + residual capture): flow-mode SRX does not route multicast by default, so most configs have none — but a multicast-related task has nothing to anchor on unless the parser records whether multicast routing exists at all. Mirror the control-plane-protection handling: emit a presence flag and push full detail to residual_raw. Detect and flag:
Set system.multicast_routing { present: true, protocols: [...] } listing the families seen (e.g. ["igmp","pim"]); absent → present: false. Send the stanza detail to residual_raw. This is a presence flag so downstream skills can reason about "is this box doing multicast routing at all" — not a full multicast parse.
Screen zone binding: for each security.zones.security-zone.<z>.screen <name>, set zones[].screen = <name>. The screen option detail continues to populate the Screen/IDS Config object.
Control-plane / RE protection: when a stateless firewall { family inet filter <name> } is applied as an interface input filter on lo0 (interfaces lo0 unit N family inet filter input <name>), set system.control_plane_protection { re_filter_present: true, applied_to: ["lo0.<N>"] }. The filter terms still go to residual_raw; this is a presence flag, not a full parse.
VPN/IPsec: Full IKE/IPsec chain resolution:
IKE proposals: encryption, integrity, DH group, lifetime, auth method (PSK vs certificate including RSA/DSA/ECDSA)
IKE policies: mode, proposals list, PSK presence (mask the value as "****"), local certificate
IKE gateways: peer address, external interface, IKE version (v1-only/v2-only), local/remote identity
IPsec proposals: encryption, integrity, lifetime
IPsec policies: proposals list, PFS group
IPsec VPNs: bind-interface, IKE gateway reference, IPsec policy reference, establish-tunnels
DHCP Server:access.address-assignment.pool — network, address ranges (low/high), router (gateway), name-server, maximum-lease-time, domain-name. Match pools to interfaces via dhcp-local-server group bindings using IP prefix matching.
DHCP Relay: Two forms:
Legacy: forwarding-options.helpers.bootp.server
Modern: forwarding-options.dhcp-relay.server-group / group / active-server-group / interface
Link relay server groups to per-interface dhcp_relay fields.
12. Multi-Context
Detect logical-systems.<name> and tenants.<name> in the config tree.
Parse each context independently, tag all extracted items with _logical_system or _tenant.
13. Residual Config Capture
Capture all unhandled set lines. Categorize into: IDS Screens, PKI/Certificates, QoS, SNMP, VLANs, Firewall Filters, Bridge Domains, Groups, Other. Store in residual_raw for manual review.
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 NETCONF/MCP for an ops/audit task, it is fine to reason directly from the hierarchical 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, route order when relevant, and inherited/pre/post/global ordering metadata with _rule_index or a vendor-specific 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 that can never match because an earlier rule fully covers them
Overly permissive — rules with any/any source+destination or any/any zone+address+application
Missing logging — permit rules without log session-close
Disabled policies — rules with deactivate prefix
Duplicate objects — different names, same value
Empty groups — address-sets or application-sets with no members
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 skip hierarchical-to-set normalization; inactive prefixes, bracket lists, and quoted strings affect extraction.
Zone-local address books are valid in older designs; migrate or normalize to global only with a warning.
Logical-systems and routing-instances are separate contexts; preserve them instead of merging names blindly.
Policy matching depends on NAT order and translated addresses; preserve both faithfully for downstream interpretation.
Management (fxp*), fabric (fab*), and HA control interfaces need special handling and should not be naively treated as ordinary security-zone interfaces. By contrast, reth* redundant-Ethernet interfaces ARE ordinary dataplane interfaces in a chassis cluster and must be parsed as zone interfaces — do not exclude them.
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
