Hexward Labs

Firewall migration

Cisco ASA to Palo Alto: the mapping, and the traps

Most ASA to PAN-OS migrations do not fail on the rules. They fail on the traffic the ASA was permitting that was never written as a rule at all. This page covers the concept mapping, the four places it breaks, and how to sequence the work so the change window is boring.

Written by a network security engineer · last reviewed 20 August 2026

If you were going to use Expedition: Palo Alto ended support for it in January 2025 and the supported replacement for config migration is a paid professional services engagement. The full picture is here.

The concept mapping

ASAPAN-OSWhere it gets awkward
nameif interface Zone Not one-to-one. Several ASA interfaces often belong in one zone, and one ASA interface sometimes needs splitting.
security-level no equivalent The single biggest trap. See below.
object network / object-group network Address object / address group Mostly clean. Watch name character rules and length limits.
object-group service Service object / service group Clean, but see the App-ID section — a literal port translation leaves value on the table.
access-list + access-group Security policy rule ASA binds an ACL to one interface and direction. PAN-OS rules carry source and destination zone. The rewrite is real work.
Auto NAT (object nat) NAT rule Usually converts cleanly.
Manual / twice NAT (nat (in,out) source … destination …) NAT rule No single clean equivalent. Convert by hand and verify each one.
Implicit inbound deny interzone-default deny Same outcome, different mechanism.

Trap 1 — security levels are not written down anywhere

On an ASA, traffic from a higher security level to a lower one is permitted by default. Nobody wrote a rule for it. It is a property of the platform.

PAN-OS has no such concept. Inter-zone traffic is denied unless a rule permits it.

So if you translate the ASA rule set faithfully — every ACL line becomes a security policy rule — you will have correctly migrated every rule and still broken production, because a large part of what the ASA allowed was never a rule.

What to do. Before the change window, take a traffic sample from the live ASA — connection table, NetFlow, syslog for permitted sessions — and reconcile it against your translated rule set. Anything in the sample that your new policy would deny is a flow that lived on implicit permit. Those are the rules you have to write from scratch, and they do not exist in the config you are converting.

This is the check that decides whether the cut-over is quiet, and no converter can do it for you — it needs data from the running device, not the config file.

Trap 2 — twice-NAT

ASA's manual NAT translates source and destination in a single statement, evaluated in a section order that also interacts with auto NAT. PAN-OS expresses the same intent differently, and the ordering semantics do not carry over.

Convert NAT last, after interfaces, zones, objects and rules are settled, and verify every twice-NAT statement individually against the original. If you only hand-check one category in the whole migration, make it this one.

Trap 3 — App-ID, and the temptation to skip it

A literal conversion gives you a port-based policy on a platform whose main advantage is that it does not need one. That is a real loss — but converting to App-ID during the migration is how change windows overrun.

The sequence that works:

  1. Migrate port-based, faithfully. Cut over. Prove the network behaves.
  2. Run in that state long enough to collect application traffic on the new device.
  3. Convert rules to App-ID afterwards, in batches, with the data to back each change.

Two changes at once means that when something breaks you cannot tell which change broke it.

Trap 4 — what does not convert at all

These need rebuilding by hand regardless of tooling. Plan the hours:

The failure worth guarding against is not “this did not convert”. It is “this did not convert and nobody was told”. Keep an explicit list, with the source line each item came from.

A converter that runs on your machine

RuleForge parses an ASA show running-config into a vendor-neutral model and generates PAN-OS set commands — or a Panorama device-group variant. It runs offline as a single Go binary. Nothing is uploaded anywhere, because a firewall configuration is the most sensitive text file in your estate and it has no business leaving your network, including to me.

The pipeline mirrors the manual order above, deliberately:

  1. Analyze — full inventory: interfaces including VLANs and port-channels, zones, objects, rules, all four NAT shapes, routes. VPN, certificates, dynamic routing, HA and App-ID features are captured with their source lines and reported for manual rebuild rather than dropped.
  2. Map — it proposes an interface-to-zone map with PAN-OS-legal names; you edit and approve it. Conversion never runs on an unseen map.
  3. Convert — object names preserved, literals wrapped in collision-safe helper objects, name transforms applied per PAN-OS character rules.
  4. Review — per-element outcomes and a before/after comparison per category. The generated config is re-parsed and diffed against the model, so verification is mechanical rather than a reading exercise.

Every job produces a Conversion Process Report — every element and its outcome, as self-contained HTML that prints to PDF. That is the artefact your change board wants.

What it does not do

Run it

Grab the tarball and SHA256SUMS from the releases page, then:

sha256sum -c SHA256SUMS
tar xzf ruleforge-free-*-linux-amd64.tar.gz
./ruleforge
# dashboard on http://127.0.0.1:8428

Or build from source: go build ./cmd/ruleforge.

Source on GitHub The full migration landscape

It converts between any two of Cisco ASA, Cisco FTD, PAN-OS, FortiGate and Check Point — so the same tool covers the reverse direction, and the estate you inherit next year. Paid editions are on Whop; licensing is offline Ed25519 and nothing phones home in either edition.