# Firewall Config Conversion > Convert parsed configurations among Cisco ASA/FTD, FortiGate, PAN-OS, and Juniper SRX with a fidelity report. Use when migrating objects, policy, NAT, zones, routing, HA, or VPN and producing target-native CLI with converted, caveat, and manual classifications. Parse raw configs first; output is not production-ready. - Skill: `fastrevmd-lab/firewall-config-conversion` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add fastrevmd-lab/firewall-config-conversion` - Raw SKILL.md: https://api.skillmd.com/api/skills/fastrevmd-lab/firewall-config-conversion/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - License: MIT - Author: fastrevmd-lab (https://skillmd.com/u/fastrevmd-lab) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fastrevmd-lab/firewall-config-conversion --- # Firewall Config Conversion ## Overview Use this skill to convert a firewall or NGFW configuration from one vendor to another by pivoting through the `parsing-*` intermediate JSON schema. Any source vendor that has a parser (Cisco ASA/FTD, FortiGate, Palo Alto PAN-OS, Juniper SRX) can be converted to any of the four supported targets, because every conversion reads the same normalized schema — `address_objects`, `address_groups`, `service_objects`, `service_groups`, `security_policies`, `nat_rules`, `zones`, `interfaces`, `static_routes` / `virtual_routers` / routing, `vpn_tunnels`, `ha_config`, and `system` (abbreviated — see the canonical `intermediate-schema.md` in the `parsing-srx-configs` skill for the full top-level structure) — and re-emits it in the target's native CLI. This schema-pivot design means there is one emitter per target rather than one translator per source/target pair. The output is always two parts: the target vendor's native configuration, followed by a per-section fidelity report. The config carries inline `# CAVEAT:` comments wherever a translation is lossy or approximate, and the fidelity report classifies each schema section as converted, converted-with-caveats, or manual-not-converted, then lists the manual follow-up items that a human must complete on the target device. This skill produces a migration draft, never a production-ready config. Vendor security models differ enough — zones versus security-levels, App-ID versus port-based services, routing-instances versus contexts or vsys — that no automated conversion is safe to commit unreviewed. Secrets are never emitted: VPN pre-shared keys, certificates, and admin passwords are always replaced with placeholders and flagged as manual items, so the draft can be shared and reviewed without leaking credentials. ## Scope and routing Convert only normalized parser output and only to vendors with an emitter in `references/`; never improvise unsupported target syntax. Route audits to `firewall-best-practices-audit` and comparisons to `firewall-config-diff`. ## 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. ## Input Handling Route on what you were given: - **Parsed intermediate schema** (the vendor-neutral JSON produced by any `parsing-*` skill; the schema definition lives in the `parsing-srx-configs` skill) — convert directly. Read `metadata.source_vendor` to label the draft and to choose source-aware caveats (`metadata.source_vendor` is the canonical schema field; for robustness also accept a legacy `metadata.vendor` key if a non-conformant parse provides one — read whichever is present). - **Raw config** — identify the vendor from the syntax, run the matching `parsing-*` skill (`parsing-cisco-configs`, `parsing-fortinet-configs`, `parsing-palo-configs`, `parsing-srx-configs`) to produce the intermediate schema, then convert the result. Never re-implement parsing in this skill. - **Target vendor** — the user must pick the target (Cisco ASA/FTD, FortiGate, PAN-OS, or SRX). If they did not, ask before emitting; there is one emitter per target and the wrong one produces unusable output. ## Conversion Workflow 1. **Confirm inputs.** Verify you have the intermediate schema (parse raw config first), read `metadata.source_vendor` for the source, and confirm the user's chosen target vendor. 2. **Load references.** Load `references/feature-mapping.md` for the cross-vendor concept map, plus the appropriate target emitter file (`references/emit-srx.md`, `references/emit-palo.md`, `references/emit-fortinet.md`, or `references/emit-cisco.md`) for the native syntax of each section. 3. **Emit each section.** Walk the schema sections in the output order below and emit each in the target's native CLI. Where a construct does not map cleanly, emit the closest equivalent and insert an inline `# CAVEAT: ...` comment explaining the approximation. 4. **Classify for the report.** As you emit, classify each section as converted, converted-with-caveats, or manual-not-converted, and collect the manual follow-up items. 5. **Placeholder all secrets.** Replace every PSK, key, certificate, and password with a clearly-marked placeholder and add a manual item to re-key on the target — never emit a real or parsed secret. 6. **Produce the output.** Emit the labeled draft config first, then the fidelity report, in the templates below. ## Output & Fidelity Report ### Conversion output (emit in this order) ```text # Conversion DRAFT: -> # Review required. Not production-ready. Manual items listed in the fidelity report. ``` ### Fidelity report (after the config) ```text Fidelity report ( -> ) Section: address_objects → () Section: zones → ... Section: security_policies → ... Section: nat_rules → ... Section: interfaces → ... Section: routing → ... Section: vpn_tunnels → ... Section: ha_config → ... Section: system / admin → ... Manual items (must do on target): 1. 2. ... ``` ## Reference Material (load on demand) - `references/feature-mapping.md` — cross-vendor concept map (zones vs security-levels, App-ID vs port services, routing-instances vs contexts/vsys, NAT models) and what is lossy in each direction. - `references/emit-srx.md` — emit the schema as Juniper SRX `set` configuration. - `references/emit-palo.md` — emit the schema as Palo Alto PAN-OS configuration. - `references/emit-fortinet.md` — emit the schema as FortiGate `config` blocks. - `references/emit-cisco.md` — emit the schema as Cisco ASA/FTD configuration. - `references/example-conversion.md` — a worked conversion against a parsing-* fixture, with its fidelity report. ## Common Pitfalls - Claiming the converted config is production-ready — it is a draft; require review plus the manual items. - Emitting secrets — PSKs, keys, and passwords are always placeholders plus a manual caveat. - Silently dropping a section with no target equivalent — report it as manual-not-converted. - Re-implementing parsing instead of delegating to the matching `parsing-*` skill. - Forcing a 1:1 mapping where the target model differs (zones vs security-levels, App-ID vs port services, routing-instances vs contexts/vsys) — emit the closest form plus a CAVEAT. - Converting interface, routing, and system sections verbatim — these are platform-bound; remap and flag naming and protocol semantics. - Losing rule or NAT order — preserve order in the emitted config. ## Verification Checklist - [ ] Confirm input is the intermediate schema (parse raw first) and the target vendor is chosen. - [ ] Every emittable schema section is either converted or explicitly reported (no silent drops). - [ ] Inline CAVEAT comments mark every lossy/approximate translation. - [ ] No secrets in the output (PSKs/keys/passwords placeholdered). - [ ] Rule and NAT order preserved. - [ ] Output labeled a migration draft; fidelity report lists all manual items.