FortiGate stacks per-appliance licensing with FortiGuard subscription bundles (IPS, web filtering, antivirus, app control) that add up across the fleet, with key features gated behind higher tiers. For edge, branch, and segmentation firewalling, OPNsense, open-source, on commodity hardware, with Suricata-based IDS/IPS, removes the subscription tax. As always, be clear about the FortiGate features that don’t have an open one-to-one.
What carries over, and what doesn’t
OPNsense handles stateful firewalling, NAT, IPsec/OpenVPN/WireGuard VPNs, and Suricata IDS/IPS very well. What does not map cleanly from FortiGate: deep application control and FortiGuard’s curated app/web categories, the SD-WAN orchestration FortiGate is known for, Security Fabric integration, and FortiManager-style central management at scale. Suricata gives you IPS, but it’s not a drop-in for FortiGuard application control. OPNsense is a great fit for edge/branch/segmentation; if your security model leans heavily on FortiGuard app-control or Fortinet SD-WAN, scope that gap honestly.
The FortiGuard features that don’t map
FortiGate policy is often written against FortiGuard’s curated categories: application-control rules that identify traffic by app regardless of port, and web-filter rules keyed to categorized URL sets. OPNsense rules match on interface, address, and port, so an application-control rule has to be re-expressed in those terms, and where an app is genuinely port-agile that policy cannot move at the same fidelity. FortiGuard’s antivirus and curated category feeds are a licensed bundle with no single open equivalent; on OPNsense you approximate the pieces with Suricata for signatures and web-proxy plugins for filtering, each tuned by you. SD-WAN is the other common blocker: FortiGate’s centralized link-steering rule engine has no open one-to-one, though OPNsense supports multi-WAN and policy-based routing for simpler cases. Inventory which policies actually depend on these features. Where the answer is “few,” the segment moves cleanly; where a site’s control genuinely rests on FortiGuard app-control or Fortinet SD-WAN, keep FortiGate there.
Size for inspected throughput
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%. FortiGate’s ASIC offload (NP/CP processors) accelerates inspection; OPNsense runs on general-purpose CPU, so provision hardware (CPU, NIC, AES-NI) with real headroom. Account for IPsec VPN throughput, concurrent sessions, and connections/sec. Under-sizing is how these projects fail.
How the migration runs end to end
- Inventory the FortiGate policy, NAT, address/service objects, and VPN config; document IPS/AV/web-filter profiles and the FortiGuard features actually in use; note HA and SIEM/logging integrations and any SD-WAN rules.
- Deploy OPNsense in HA (CARP), and recreate firewall rules, aliases, and NAT. FortiGate’s object-and-policy model maps to OPNsense aliases and rules, rebuild rather than import.
- Migrate VPNs, IPsec site-to-site tunnels and remote access (OpenVPN/WireGuard), and enable Suricata IDS/IPS with the relevant rulesets.
- Wire logging to your SIEM and confirm visibility parity.
- Pilot at a low-risk site, validate an allow/deny matrix and VPN connectivity live, then roll out site by site with rollback ready.
Translating FortiGate policy without a converter
No converter turns a FortiGate config into an OPNsense ruleset, so the export is reference material, not an input. Pull the address and service objects, the NAT policies, and the firewall policy table first. Recreate the objects before any rule: FortiGate address and service objects and their groups become aliases under Firewall, Aliases, and because aliases nest, a FortiGate group-of-groups maps directly. Building aliases first means rules reference names, and you can re-point a whole class of rules by editing a single alias later.
Then translate each FortiGate policy into an OPNsense rule on the matching interface, preserving order. FortiGate policies are evaluated top-down and so is the OPNsense ruleset per interface, so a deny that sat above a broad permit must keep that relative position or the rebuild silently loosens. FortiGate’s implicit deny-all becomes OPNsense’s default-deny inbound; make it explicit with a logged catch-all block at the bottom of each interface so you can see what it catches. Take NAT as a separate pass: FortiGate couples policy and NAT, OPNsense separates them, so recreate outbound (source) NAT and port forwards under the NAT sections and review any auto-generated pass rule rather than trusting it.
Rebuilding tunnels and the IPS layer
Rebuild FortiGate IPsec site-to-site tunnels under VPN, IPsec with phase-1 and phase-2 parameters matched to each peer exactly, and move remote-access users to OpenVPN or WireGuard. For the FortiGuard IPS function, enable Suricata under Services, Intrusion Detection and migrate your signatures across, starting in alert-only mode on the WAN and inter-segment paths. Tune out the false positives on real traffic before you flip Suricata to blocking, because a freshly loaded ruleset in blocking mode will drop legitimate flows. Remember that FortiGate offloads inspection to its NP and CP processors while OPNsense inspects on general-purpose CPU, so validate that inspected throughput holds on your chosen hardware before you rely on the box.
Rolling out one site at a time
Never replace every firewall at once. Pilot one site, monitor logs and IPS for anomalies during hypercare, then expand. Roll back by re-pointing traffic to the FortiGate, keep it racked and configured until each site validates.
The checks that gate cutover
Acceptance bar: rule/NAT correctness (allow and deny), VPN connectivity (site-to-site and remote), IDS/IPS detection and throughput, and an HA failover test. Confirm deny rules actually block and throughput holds with inspection enabled before retiring the FortiGate.
Where you land
FortiGate → OPNsense removes per-appliance and FortiGuard-subscription cost for edge and segmentation firewalling, in exchange for losing FortiGuard app-control and Fortinet SD-WAN-class features you may need to replace. Size for IPS+TLS throughput on general-purpose CPU, rebuild policies and VPNs, and cut over site by site with the FortiGate as fallback. Model your per-firewall savings in the calculator above, and treat them as illustrative until you confirm throughput and feature requirements.