OPNsense → Fortinet FortiGate

OPNsense ↔ Fortinet FortiGate: integration to migration path.

Your firewall is load-bearing — break it and a whole segment goes dark at once. So OPNsense never replaces FortiGate on a cutover day. It racks up alongside FortiGate first, observes real traffic in passive mode, then takes the data path one segment at a time while FortiGate keeps owning FortiGuard UTM, ASIC offload, and the reporting auditors recognise for as long as those actually earn their keep.

This is a partial path by design. App Control, FortiSandbox, FortiGuard cadence, SD-WAN steering, and ASIC offload are SaaS-only — FortiGate UTM and FortiAnalyzer often stay in production after the OPNsense migration completes. We say which case you're in before anything moves.

The idea

Take the forwarding plane segment by segment. Leave UTM with FortiGate.

The topology that makes this zero-downtime: an OPNsense HA pair (CARP VIPs plus pfsync) runs in routed mode and owns L3/L4 forwarding, NAT, IPsec and WireGuard, and east-west policy, while FortiGate is repositioned behind it as a UTM bump-in-the-wire — often a Transparent VDOM so it doesn't re-NAT — for the traffic classes where FortiGuard IPS, AV, and web filtering genuinely earn their keep. OPNsense stands up in parallel and observes first; each segment cuts to it only after its rule translation is signed off, and each cut is reversible.

The phases

Six steps. Each one reversible.

0

Baseline & inventory

We capture every FortiGate policy by source and destination interface, address, service, and action, plus each UTM profile binding (AV, IPS, web filter, App Control), the NAT model, VIP table, IPsec proposals, FSSO topology, and ASIC utilisation per appliance. Read-only; nothing moves.

Users see: No user impact.

Rollback: N/A.

1

OPNsense HA in parallel, observing

An OPNsense HA pair (CARP VIPs, pfsync) is racked on the management network only — never in the data path. A SPAN or TAP feeds Suricata in alert-only IDS mode so we can baseline the ruleset and false-positive rate against real traffic. FortiGate is untouched.

Users see: None.

Rollback: Power off OPNsense; it never touched the data path.

2

Translate policy offline

We mechanically translate the first segment's FortiGate policies into OPNsense rules and aliases, committed to git. The hard part is the UTM bundle: each profile becomes a tuple of pf rule plus Suricata SID set plus ClamAV mount-point plus DNS RPZ entry, with the coverage loss documented honestly per policy. Still not deployed.

Users see: None.

Rollback: N/A — nothing is deployed.

3

Cut the first low-risk segment

A low-risk segment — guest WiFi or a non-prod DMZ — has its default gateway moved to an OPNsense CARP VIP, with FRR-BGP peering pre-staged in passive mode. Suricata flips to inline IPS for the segment after 7 clean days in IDS mode on real traffic.

Users see: None if the rule translation is faithful. A documented ARP-cache flush avoids brief asymmetric routing.

Rollback: Revert the gateway to the FortiGate VIP or VDOM. Under 15 minutes while the FortiGate config is left intact during the bake.

4

Iterate per segment in waves

Remaining in-scope segments cut over in waves of increasing blast radius — guest, then DMZ, then server VLANs, then user VLANs, with the datacentre interconnect last. New FortiGate policy is frozen for in-scope segments; all new policy goes through the git pipeline to OPNsense.

Users see: None.

Rollback: Per-segment rollback as in Phase 3. After 30 days post-cut the segment is committed and the FortiGate-side policies are tagged for decommission.

5

Decommission in-scope; retain where SaaS won

FortiGate at in-scope perimeters is powered down once it shows zero forwarded sessions. Where UTM cadence, vendor-attested IPS evidence, or ASIC throughput is load-bearing, FortiGate stays in production. FortiManager ADOMs slim to the retained fleet; FortiAnalyzer keeps ingesting their logs.

Users see: None.

Rollback: Within a 30-day evidence window the appliance can be re-energised and traffic shifted back. After that window, rollback is out of scope.

Feature parity

Where OPNsense matches FortiGate — and where it honestly doesn't.

CapabilityOPNsenseFortinet FortiGateParity
Stateful L3/L4 firewall pf rules plus aliases (host/net/port/URL-table), quick short-circuit, Floating tab FortiOS Policy (iprope), Central vs per-policy NAT At parity
Application identification Suricata custom sigs on tls.sni / http.host / dns.query (plus optional Zenarmor) FortiGate App Control plus FortiGuard ISDB (SaaS-by-IP) SaaS only
IPS / IDS Suricata plugin (os-ids) inline IPS, ET Open / ET Pro FortiGuard IPS sensor Partial
Malware sandbox None native; ClamAV-via-Squid/ICAP for file scan only FortiSandbox / FortiGuard AV SaaS only
URL filtering Unbound RPZ plus DNSBL feeds (OISD / Hagezi); Zenarmor categories (paid) FortiGuard Web Filter categories Partial
VPN (IPsec / WireGuard) strongSwan (os-ipsec) IKEv2 plus first-class WireGuard (os-wireguard) FortiOS IPsec; WireGuard native in 7.2+ At parity
Routing (BGP / OSPF) FRR plugin (os-frr) OSPFv2/v3, BGP, software BFD FortiOS native multi-protocol, hardware-assisted BFD At parity
HA / clustering CARP VIPs plus pfsync state sync (active/passive) FortiGate FGCP HA cluster At parity
Central management git config.xml plus Salt/Ansible plus REST API (plus AWX RBAC bolt-on) FortiManager ADOMs (policy-package, RBAC, revisions) Partial
Threat intel feed cadence ET Open roughly daily, ET Pro faster FortiGuard feeds, sub-hourly emergency releases SaaS only
ASIC / hardware offload Commodity x86 software-only (AES-NI / QAT where present) FortiGate NP/SP/CP SPU offload SaaS only
Logging filter.log plus Suricata eve.json; NetFlow via os-netflow FortiAnalyzer (hit counters, prebuilt reports) Partial
Cost model Community free; Business Edition support Per-appliance FortiOS plus FortiGuard plus FortiManager plus FortiAnalyzer At parity
Compliance (PCI / SOC 2) Self-operated Suricata to a documented baseline; you own the control Vendor-attested IPS evidence; FortiAnalyzer reports auditors recognise Partial

What we're honest about

The gaps most vendors leave out.

FortiGuard feed cadence and App Control have no clean OSS twin

FortiGuard ships sub-hourly emergency IPS, AV, and web-filter releases; ET Open is roughly daily and ET Pro, while faster, still lags. App Control plus the ISDB identifies SaaS by rotating IP range — Suricata custom rules on tls.sni and http.host cover materially less. We pair ET Pro with custom SID development, move app-aware policy to a higher layer (CASB, SaaS-edge, EDR DNS filtering), and keep FortiGate where the cadence is non-negotiable.

No malware sandbox or SD-WAN parity

FortiSandbox and FortiGuard AV have no native OPNsense equivalent — ClamAV via Squid or ICAP does file scan only. FortiGate SD-WAN's app-aware path selection over multiple underlays also has no native parity; policy-based routing by IP and port breaks for SaaS over 443 with rotating ranges. Where SD-WAN steering is load-bearing, FortiGate stays at the hubs.

FSSO identity and FortiClient ZTNA posture move off the firewall

FortiGate policies that are user-identity-aware via FSSO, and FortiClient endpoint posture tags (patch level, AV state, disk encryption), have no OPNsense equivalent. Identity moves to FreeRADIUS with 802.1X, captive portal, or a proxy/EDR layer; ZTNA proper is a separate platform decision we never bundle into the firewall migration.

Self-hosting means you own uptime, throughput, and the audit story

An OPNsense HA pair down means that perimeter is down — no managed backstop, so we run CARP plus pfsync on a dedicated sync interface, warm-spare hardware, and a DR runbook with an RTO target. Commodity x86 also runs roughly two to five times lower L4 throughput than FortiGate's NP/SP/CP ASIC, worse with IPS on. And PCI 11.4 evidence becomes you operating Suricata to a documented baseline rather than a vendor-attested control — so we may keep FortiAnalyzer ingesting OPNsense syslog purely for auditor-recognised reporting.

Why this beats a flag day

Reversible per segment, soaked before anything is cancelled.

Every cut has a tested rollback path under 15 minutes — revert the segment's gateway to the FortiGate VIP or VDOM while the FortiGate config is left intact during the bake, and you're back, with on-call network and security signed off on the procedure. And no FortiGate appliance is retired on faith: a perimeter only clears its gate after its segments soak at least 30 consecutive days within plus or minus 10 percent of the pre-cut baseline, the appliance shows zero forwarded sessions for at least 14 days, and a 30-day evidence window passes before the subscription is flagged for non-renewal.

See whether your policy set migrates cleanly.

A 30-minute call with a senior firewall engineer. We classify your FortiGate policies and UTM bindings, find the segments OPNsense can take, and tell you honestly which planes — App Control, FortiSandbox, SD-WAN, FSSO, ASIC throughput — should stay on FortiGate. Before you commit to anything.

Map my migration →