Srx Initial Setup

SRX first-time setup

Overview

Use this skill to bring a new or factory-reset Juniper SRX from its shipped state to a reachable, zoned, screened, and minimally policied device. It automates Day-0 and Day-1 setup for Branch SRX300/400, campus SRX1600/4120, and datacenter SRX4300/4700/5000 platforms.

Architecture: assess-first, close only open gaps. This skill ALWAYS opens with a read-only entry-state assessment that determines current device state — factory-default, bare, partial, configured, or unreachable. It then computes a dependency-ordered gap list and proposes changes to close only the gaps that are actually open. Re-running it against a finished device proposes nothing and just reports the verification matrix.

Every device write runs behind a per-stage approval gate under confirmed commit with a rollback timer. If verification fails, the confirmed commit expires automatically and Junos rolls back to the pre-change configuration.

Validation status: At 1.3.0 this skill has been run end-to-end against a live SRX345 (srx345-dual-ac, Junos 21.2R3-S6.11, 2026-08-25) from factory-default state through the baseline policy stage. Both the read path and the write path are hardware-validated: the gate protocol, commit confirmed, per-stage verification, and the confirming commit were exercised on every stage. Eleven claims were corrected — see the validation record in references/factory-default-branch.md. Four of the eleven were silent failures that would have reported a gap closed while changing nothing or while degrading the device. Still unvalidated on hardware: rollback-on-verification-failure (no stage failed verification during the run), the other Branch SKUs, and all campus and datacenter platforms. Platform scope: Branch SRX300/400, campus SRX1600/4120, datacenter SRX4300/4700/5000. SRX1500 is end-of-sale and is not a validation target.

Scope and routing

Use this skill for first-time setup, Day-0 and Day-1 bring-up, factory-default removal or adoption, establishing management access (SSH, NETCONF), system services (NTP, DNS, hostname), creating interfaces and security zones with host-inbound-traffic rules, applying starter IDS screens, establishing a baseline security policy, and reading licensed feature entitlement and operational state.

Boundaries — this skill routes away for:

1. Chassis cluster formation. If the device is part of a chassis cluster or cluster formation is the intent, route to srx-chassis-cluster-proxmox or srx-mnha. This skill handles standalone SRXs only. If the entry-state assessment detects cluster membership, it stops immediately and routes away.

2. Licensing mutation. This skill reads feature entitlement and operational state (entitled, configured, active) but never installs, modifies, or removes licenses. All mutating license work routes to srx-license-signature-maintenance.

3. ZTP-based provisioning. This skill does not provision devices via Zero Touch Provisioning, and it does not configure a ZTP server, DHCP options 43/66, or image staging. It does, however, disable the factory-default chassis auto-image-upgrade as a Day-0 gap — because on a Branch SRX that setting actively resets DHCP client state and can install an image and reboot unattended while setup is in progress. Turning ZTP off is in scope; using ZTP is not.

4. Policy design beyond the baseline. This skill establishes the minimum security policy required to make the device usable: outbound DNS, web, and NTP, plus default-deny with logging. The baseline is generated using global policies; when a zone-pair exception applies, the policy stage routes to srx-policy for non-Branch platforms (see references/stages/baseline-policy.md for Branch limitations). Application-aware policies, URL filtering, intrusion prevention, and advanced security services route to srx-policy (non-Branch platforms only; Branch SRX zone-pair policy is unowned).

Runtime intake

Before starting the workflow, inspect the request, supplied artifacts, and available approved read-only evidence. If unresolved facts could materially change safety, scope, correctness, confidence, or the requested output, read references/runtime-intake.md.

For each unresolved material fact whose catalog condition is true, invoke Claude AskUserQuestion or Codex request_user_input before continuing or issuing an open-ended request. Ask at most three single-select catalog questions per round. After each response, ask another round whenever any unresolved material catalog condition remains true; continue only when none remain. Do not repeat answered questions or show the full catalog. Without a native tool, present each selected catalog question with its 2-3 labeled choices and a free-text Other path in concise plain text; do not substitute a generic checklist. Never request secrets or unredacted customer data. Treat intake answers as task context, not approval for a live change; obtain separate explicit approval before configuration, commit, upgrade, reboot, delete, or failover actions.

1. Entry-state assessment (read-only)

The skill ALWAYS opens with a read-only assessment that establishes current device state before any write is proposed. This assessment classifies the device into exactly one of five entry states:

Read-only evidence commands:

• show version — hostname, model, Junos OS version
• show chassis hardware — chassis inventory, platform series
• show chassis cluster status — cluster membership (stop and route away if detected)
• show configuration chassis — phone-home ZTP (auto-image-upgrade); the strongest single factory-default signature, and a blocking gap if present
• show interfaces terse — configured units and operational states
• show security zones — zones, interface bindings, host-inbound-traffic
• show security screen ids-option — screen profiles
• show security policies — policy table
• show configuration system — root auth, DNS, NTP, services, hostname

Full command catalog and output parsing: references/entry-state-assessment.md.

Entry-state classification is deterministic. The same device state produces the same entry state on every run. Assessment reads current state rather than trusting a prior run, so this skill is idempotent: re-running against a device with no open gaps produces the verification matrix and proposes nothing.

2. Gap list

A gap is a structured record of a single missing or incorrect configuration element. Every proposed change to the device exists as a gap first.

Gap schema:

Severity:

• blocking — later stages cannot proceed until this gap closes. Example: mgmt.ntp-absent is blocking because accurate timestamps are required for later stages.
• advisory — recommended but not required for later stages. Example: timezone unset may be advisory if NTP is configured.

Dependency ordering: Gaps close in dependency order. A gap whose depends_on is unsatisfied is not offered. factory.* gaps depend on management-plane stage completion because factory-default removal is lockout-risk and the replacement management path must be established first. One documented exception: factory.auto-image-upgrade depends on nothing and closes first, because ZTP interferes with establishing the management plane itself and carries no lockout risk.

Gap namespaces: access.*, mgmt.*, zone.*, screen.*, policy.*, factory.*. Each stage reference populates its own namespace.

Full gap model, namespaces, ordering rules, and idempotency contract: references/gap-model.md.

Gate protocol

Every lockout-risk change follows a six-step protocol: assess read-only, show the candidate change as a configuration diff, obtain explicit approval for this stage, apply under confirmed commit with a rollback timer, verify reachability and the stage's success criteria, and issue the confirming commit only after verification succeeds. Approval of one gate never implies approval of the next, and a bare commit is never issued on a remote session.

If verification fails while a confirmed commit is pending, do NOT issue the confirming commit. Let the timer expire; Junos will automatically roll back to the pre-change configuration.

Confirmed commit mechanics, timer default, rollback points, recovery-path requirements, and verification-failure handling: references/write-safety.md.

3. Stages

Five stages execute in dependency order. Each stage closes only its open gaps; completed stages are skipped.

Stage 1: Access and Recovery

Establishes authenticated access and confirms out-of-band recovery capability before any lockout-risk configuration is applied.

What this stage establishes:

• Root authentication (encrypted password or SSH key)
• Named administrative user with configuration privileges
• SSH and NETCONF access enabled
• Out-of-band access confirmation (console or equivalent recovery path)

Gaps: access.root-auth-absent, access.no-named-admin, access.ssh-disabled, access.netconf-disabled.

All gaps except access.netconf-disabled are blocking. NETCONF is advisory for manual workflows but required for automation.

Lockout risk: Setting root auth or creating the first named admin does not remove an existing path; it creates the initial one. These gaps carry lockout_risk: false. SSH/NETCONF enablement carries no lockout risk either.

Full stage reference: references/stages/access-and-recovery.md.

Stage 2: Management Plane

Establishes system identity, time synchronization, name resolution, and management network addressing.

What this stage establishes:

• System identity (hostname and domain name)
• Time synchronization (NTP configured and operational, including the hidden set system processes ntp enable statement)
• Name resolution (DNS name servers configured)
• Management addressing (fxp0 or chosen revenue interface with routable address)

Gaps: mgmt.hostname-absent, mgmt.domain-absent, mgmt.dns-absent, mgmt.ntp-absent, mgmt.timezone-unset.

NTP is where downstream log management silently fails. A skewed clock still completes mTLS to a log collector and still gets its payloads acknowledged, so transport checks pass while the logs never appear in Security Director. Prove synchronization here, before onboarding. set system processes ntp enable is hidden from CLI completion — it will not tab-complete, which is why it gets skipped — and is a valid statement on Junos 24.2 through 26.2; its absence is not the same as disabled, and the gate is show ntp associations, not the statement. See references/stages/management-plane.md.

All gaps are blocking for the factory.* stage. Factory-default removal is lockout-risk; the replacement management path must be established and verified first.

Management interface choice: The decision between fxp0 (dedicated out-of-band management interface) and a revenue port (data-plane interface subject to security zones and policies) depends on platform capabilities, network topology, and deployment requirements. This skill does not re-derive that analysis; the reasoning is owned by the srx-syslog-logging skill's fxp0-and-management-vrf reference.

Lockout risk: Changing the management interface address or its routing instance can sever the active session. Management-plane gaps with lockout risk follow the gate protocol.

Full stage reference: references/stages/management-plane.md.

Stage 3: Interfaces and Zones

Establishes network segmentation boundaries, interface addressing, and host-inbound-traffic rules that control which services can reach the device itself.

What this stage establishes:

• Security zones (trust, untrust, mgmt)
• Interface addressing (Layer 3 addresses on physical and logical interfaces)
• Zone-to-interface assignment
• Host-inbound-traffic rules (SSH, HTTPS, ping, NTP on trusted zones; no management services on untrust)

All zone.* gaps are blocking for later stages. Security policies require zones to exist. Screens bind to zones, not interfaces directly.

Lockout risk: Of all stages, this one carries the highest lockout risk because changing the interface currently carrying management traffic or its zone membership can sever the active session. All lockout-risk gaps in this stage follow the gate protocol.

Host-inbound-traffic is the mechanism that permits system services and routing protocols to reach the device itself. Without explicit host-inbound-traffic rules, SSH and NETCONF are refused even if the service is globally enabled.

Full stage reference, including host-inbound-traffic mechanics and verification commands: references/stages/interfaces-and-zones.md.

Stage 4: Starter Screens

Applies a conservative set of IDS screen options to detect and block common network attacks. Screens provide defense-in-depth by inspecting traffic at the zone interface before security policy processing.

What this stage establishes:

• A starter screen profile named STARTER-SCREENS with conservative thresholds
• Screen binding to trust and untrust zones

Gaps: screen.profile-absent, screen.untrust-unscreened, screen.trust-unscreened.

Screens are NOT a substitute for security policy. They are a complementary layer that detects protocol anomalies, malformed packets, and known attack patterns before policy lookup.

Lockout risk: Screens do not affect management traffic because management services use host-inbound-traffic, which bypasses screen processing. Screen gaps carry lockout_risk: false.

Full stage reference, including recommended screen options, threshold selection, and false-positive troubleshooting: references/stages/screens.md.

Stage 5: Baseline Policy

Establishes the minimum security policy required to make the device usable: outbound DNS, web, and NTP, plus default-deny with logging.

What this stage establishes:

• Outbound internet access for DNS, HTTP, HTTPS, and NTP from trust to untrust
• Default-deny behavior as the backstop
• Session logging on key policies to provide visibility

This is not a complete policy design. It is the foundational structure that later policy work builds upon. Application-aware policies, URL filtering, intrusion prevention, and advanced security services route to srx-policy.

Why this is the minimum:

• Outbound access is required for device operation (DNS, NTP) and LAN client utility (web browsing).
• Default-deny is required for security (explicit deny-all policy with logging makes the security posture measurable).
• Logging is required for operations (without session logs, the operator cannot troubleshoot connectivity or verify policy is working).

Gaps: policy.outbound-dns-absent, policy.outbound-web-absent, policy.outbound-ntp-absent, policy.default-deny-absent.

Lockout risk: Baseline policies do not affect management traffic. Policy gaps carry lockout_risk: false.

Full stage reference, including policy ordering, logging recommendations, and verification commands: references/stages/baseline-policy.md.

Factory-default branch removal (conditional)

When the entry-state assessment detects vendor-shipped factory-default configuration on a Branch SRX300 or SRX400, this stage proposes removal of factory elements that conflict with the baseline configuration.

Factory-default elements on Branch platforms:

• chassis auto-image-upgrade (phone-home ZTP) enabled — resets DHCP client state and may install an image and reboot unattended
• Permissive default policy (trust to untrust any/any permit)
• IRB.0 DHCP server on VLAN trust (192.168.2.0/24 broadcast domain; irb.0 = 192.168.2.1/24)
• WAN DHCP clients on ge-0/0/0.0 and ge-0/0/15.0; untrust also binds dl0.0
• System services enabled on untrust per-interface (HTTPS/DHCP/TFTP; SSH is not permitted from untrust)
• fxp0 configured as 192.168.1.1/24 with a DHCP server on it — not left unconfigured

factory.* gaps depend on management-plane stage completion, except factory.auto-image-upgrade which closes first. The replacement management path must be established and verified before the remaining factory elements are removed.

Lockout risk: All factory.* gaps carry lockout_risk: true because removal of factory elements can cost management reachability if the assessment's judgment about the management path was wrong.

Full reference, including factory-default signatures, gap records, and deployment-specific IRB subnet conflict handling: references/factory-default-branch.md.

4. Entitlement readout

Read-only assessment of licensed feature entitlement, configuration, and operational state across three independent axes:

Critical finding: A license counter reporting "used" does NOT mean the feature is enforcing. To know whether IDP is actually enforcing, read the operational policy status. This finding is verified in the srx-license-signature-maintenance skill's licensing reference.

Result states: active, licensed but not configured, configured but not licensed, neither, indeterminate. When any axis is unreadable, the result is indeterminate and is reported as such.

This skill never installs, modifies, or removes a license. All mutating license work routes to srx-license-signature-maintenance.

Full entitlement readout protocol, result state definitions, routing table, and chassis-cluster entitlement checking: references/entitlement-readout.md.

5. Verification

Every stage requires verification after its gaps close. Verification proves the configuration change achieved its intended effect and that the device remains reachable.

Per-stage verification:

• Stage 1: Root and named admin authentication work; NETCONF connection succeeds (if enabled); operator confirms console or equivalent recovery access
• Stage 2: Hostname and domain configured; DNS resolution works; NTP synchronized — show ntp associations shows a * peer with non-zero reach and offset < 1000 ms, and ntp disable is absent from system processes; management interface reachable; default route active
• Stage 3: All zones exist; interfaces assigned to zones; host-inbound-traffic configured correctly; management access still works from management network
• Stage 4: Starter profile exists; screens bound to zones; screen statistics show expected behavior; logs show screen hits only for actual attacks
• Stage 5: Global policy table exists with correct ordering; policy hit counts reflect traffic; session logging working (see references/verification.md for external connectivity test requirements)

Verification must complete BEFORE the confirmed-commit timer expires. For lockout-risk changes, the gate protocol mandates a confirmed-commit timer (default duration documented in references/write-safety.md). All verification commands must execute and their output interpreted within that window.

If verification fails while a confirmed commit is pending: Do NOT issue the confirming commit. Let the timer expire; Junos will automatically roll back to the pre-change configuration.

The finished-device matrix: When this skill is re-run against a device where all gaps are already closed, the assessment phase produces a verification matrix showing the device's configured state across all areas. The skill reports "No gaps detected. Device meets baseline configuration criteria." and proposes no changes.

Full per-stage verification commands, success criteria, finished-device matrix, and verification-failure handling: references/verification.md.

Failure handling

Output contract

For each run, return:

1. Entry state (one of five: factory-default, bare, partial, configured, unreachable)
2. Gap count per stage, with severity breakdown (blocking vs advisory)
3. Proposed changes as configuration diffs, one per gap
4. Verification results per stage (pass/fail, with evidence)
5. Finished-device matrix if all gaps are closed (no writes proposed)

Never include device credentials, raw license material, internal addresses in chat output, or local secret paths.

Reference material (load on demand)

Core model and assessment:

• references/entry-state-assessment.md — Entry states, read-only evidence collection, classification logic
• references/gap-model.md — Gap schema, namespaces, severity, dependency ordering, idempotency
• references/factory-default-branch.md — Factory-default signatures, removal gaps, IRB conflict handling
• references/write-safety.md — Gate protocol, confirmed commit mechanics, timer selection, rollback behavior

Workflow components:

• references/runtime-intake.md — Material fact catalog and intake question protocol
• references/entitlement-readout.md — Three-axis assessment, result states, routing table
• references/verification.md — Per-stage criteria, finished-device matrix, failure handling

Stage references (each defines gaps, lockout risk, verification commands, and success criteria):

• references/stages/access-and-recovery.md — Stage 1: root auth, named admin, SSH, NETCONF, recovery confirmation
• references/stages/management-plane.md — Stage 2: hostname, DNS, NTP, management addressing
• references/stages/interfaces-and-zones.md — Stage 3: zones, interface addressing, host-inbound-traffic
• references/stages/screens.md — Stage 4: starter screen profile, zone bindings
• references/stages/baseline-policy.md — Stage 5: outbound DNS/web/NTP, default-deny, logging

Verification checklist

• Entry-state assessment runs read-only before any write is proposed
• Chassis cluster membership detected → skill stops and routes away
• Gap list computed from current device state, not assumptions
• Each gap has all seven required fields populated
• Gaps offered in dependency order; unsatisfied dependencies not offered
• Every lockout-risk gap follows the gate protocol (assess, show diff, approve, commit confirmed, verify, confirm)
• Confirmed commit uses timer documented in references/write-safety.md for lockout-risk changes
• Verification completes BEFORE the confirmed-commit timer expires
• If verification fails, confirming commit is NOT issued; timer expires and Junos rolls back automatically
• Re-running against a finished device produces verification matrix and proposes no writes (idempotency)
• No device credentials, raw license material, or internal addresses in chat output
• All factory-default gaps depend on management-plane stage completion, except factory.auto-image-upgrade, which closes first and carries no lockout risk
• All entitlement assessments check entitled/configured/active independently; license counter alone never treated as proof of enforcement
• All routing boundaries respected: chassis cluster → route away, licensing mutation → route to srx-license-signature-maintenance, policy design → route to srx-policy