From Palo Alto Networks to OPNsense

Palo Alto stacks per-appliance costs with per-subscription bundles (Threat Prevention, URL Filtering, WildFire), premium NGFW hardware, Panorama licensing, and steep support renewals. OPNsense (open-source, on commodity hardware) provides stateful firewalling, NAT, VPN, and Suricata-based IDS/IPS without the subscription tax, a strong fit for edge, branch, and internal segmentation. But be clear-eyed about the NGFW features that don’t have an open one-to-one.

Where OPNsense fits, and where it doesn’t

OPNsense handles firewall rules, NAT, IPsec/OpenVPN/WireGuard VPNs, and Suricata IDS/IPS very well. What does not translate cleanly from Palo Alto: App-ID (deep application identification), WildFire (cloud sandboxing), advanced User-ID integration, and Panorama-style central management at scale. Suricata signatures provide IPS, but they are not a drop-in for App-ID policy. If your security model leans heavily on App-ID/WildFire, scope that gap honestly, OPNsense is a great fit for edge/segmentation, less so as a feature-for-feature NGFW replacement in a high-assurance core.

What App-ID and WildFire actually cost you to replace

The gap is worth naming precisely, because it drives whether this migration is appropriate for a given segment. App-ID classifies traffic by application regardless of port, and much of a mature Palo Alto rulebase is written in those terms: permit this application, deny that one, independent of the Layer 4 port it rides on. OPNsense rules match on interface, address, and port, so an App-ID rule has to be re-expressed as address and port logic, and where an application is truly port-agile, some of that policy cannot be reproduced at the same fidelity. WildFire’s cloud sandboxing of unknown files has no open equivalent at all; Suricata inspects against known signatures, it does not detonate unknown samples. User-ID’s identity-to-IP mapping likewise has no direct analog. So inventory which rules actually depend on these features. In many edge and segmentation deployments the answer is “few,” and those move cleanly. Where a segment leans on App-ID or WildFire for its control, keep Palo Alto there.

Size with TLS inspection in mind

The classic firewall-migration mistake is sizing on raw firewall throughput. Size on threat-protection (IPS) throughput, and remember TLS inspection can cut effective throughput by 50–70%. Account for IPsec VPN throughput, concurrent sessions, and connections/sec, and provision hardware with that headroom. Under-sizing is how these projects fail.

The path from inventory to cutover

1. Inventory the security policy, NAT rules, address/service objects, and VPN configuration; document IDS/IPS profiles and the Palo Alto features (App-ID, URL, WildFire, User-ID) actually in use; note HA and SIEM/logging integrations.
2. Deploy OPNsense in HA (CARP), and recreate rules, aliases, and NAT. Object-heavy Palo Alto policy maps to OPNsense aliases and rules, rebuild rather than import.
3. Migrate VPNs, IPsec site-to-site tunnels and remote-access (OpenVPN/WireGuard) users, and enable Suricata IDS/IPS with the relevant rulesets.
4. Wire logging to your SIEM and confirm parity of visibility.
5. Pilot at a low-risk site, validate an allow/deny matrix and VPN connectivity live, then roll out site by site with rollback ready.

Rebuilding the rulebase by hand

There is no tool that converts a Palo Alto policy package into an OPNsense ruleset, so treat the export as documentation, not something you feed in. Pull the security policy, NAT rules, and object groups first; that is your source of truth for the rebuild. Recreate the objects before any rules: address objects and groups become aliases under Firewall, Aliases, and nesting works, so a group-of-groups in Palo Alto maps to nested aliases. Building aliases first means every rule references a name rather than a raw address, which keeps the ruleset readable and lets you re-point a whole set of rules by editing one alias later.

Then translate rules in order. Palo Alto evaluates its security policy top-down and so does OPNsense per interface, so preserve relative order carefully: a deny that sat above a broad permit must keep that position, or the rebuild quietly becomes more permissive than the original. Map each Palo Alto rule onto the correct OPNsense interface, and make any implied cleanup or drop-all rule explicit, since OPNsense is default-deny inbound but you want that intent visible and logged. Handle NAT as its own pass rather than inline with the security rules: recreate source (outbound) NAT and destination NAT (port forwards) under the NAT sections, and review any auto-created pass rule rather than trusting it blind.

Moving the VPNs and standing up Suricata

Rebuild IPsec site-to-site tunnels under VPN, IPsec with phase-1 and phase-2 parameters matched to each peer exactly; a mismatched proposal is the usual cause of a tunnel that negotiates and then drops. Move remote-access users off the Palo Alto client onto OpenVPN or, where you can, WireGuard, which is smaller and faster to stand up. For the inspection layer you were paying subscription for, enable Suricata under Services, Intrusion Detection. Start in IDS (alert-only) mode on the WAN and any inter-segment paths, tune out the false positives from your chosen ruleset, then switch to IPS blocking once the noise is gone. Blocking before you have tuned is how a migration takes down legitimate traffic on day one.

Pilot one site, keep the Palo Alto as fallback

Never replace every firewall at once. Pilot one site, monitor logs and IPS for anomalies during hypercare, then expand site by site. Roll back by re-pointing traffic to the Palo Alto firewall, keep it racked and configured until each site validates.

What has to pass before you retire the incumbent

The acceptance bar is rule/NAT correctness (allow and deny), VPN connectivity (site-to-site and remote), IDS/IPS detection and throughput, and an HA failover test. Confirm the deny rules actually block and that throughput holds with inspection enabled before retiring the incumbent.

So, is it worth it?

Palo Alto → OPNsense removes per-appliance and per-subscription cost for edge and segmentation firewalling, in exchange for App-ID/WildFire-class features you may need to replace or live without. Size for IPS+TLS throughput, rebuild the rulebase and VPNs, and cut over site by site with the Palo Alto as fallback. Model your per-firewall savings in the calculator above, and treat them as illustrative until you confirm throughput and feature requirements.