Check Point is a capable enterprise firewall, but the per-gateway licensing stacked with per-blade subscriptions and annual support uplifts makes it expensive to run at the edge of a mid-size network. OPNsense, a FreeBSD/pf-based open-source firewall, is a common destination for branch offices, smaller perimeters, and lab/DMZ segments where the Check Point feature surface is overkill. The honest framing first: this is not a config import, it is a rebuild. There is no tool that ingests a Check Point policy package and emits an OPNsense ruleset, so the work is translation and validation, done carefully.
Be realistic about the fit
OPNsense covers stateful filtering, NAT, IPsec/OpenVPN/WireGuard VPN, HA (CARP), IDS/IPS (Suricata), and reverse proxy/WAF via plugins. What it does not match is Check Point’s centralised multi-domain management, the full Threat Prevention blade suite, and identity-aware policy at the same depth. For a single site or segment, that gap is usually fine; for a large multi-site estate centrally managed from one SmartConsole, scope this as per-segment replacements, not a wholesale swap. Decide that up front.
Translating the rule base
The core task is converting Check Point’s object-and-rule model into pf rules:
- Export the policy and objects. Pull the rule base, network/host/service objects, and NAT rules (SmartConsole export or the management API). This is your source of truth.
- Recreate objects first. Build the address aliases and port groups in OPNsense (Firewall → Aliases) before any rules, clean aliases keep the ruleset readable and maintainable.
- Rebuild rules in order. Translate each Check Point rule to an OPNsense rule on the right interface, preserving evaluation order and the implicit cleanup/deny intent. OPNsense is default-deny inbound; make any implied “drop all” explicit.
- Map NAT separately. Re-create source NAT (outbound) and destination NAT (port forwards), Check Point’s automatic/manual NAT splits into OPNsense’s Outbound and Port Forward sections.
- Rebuild VPNs. Re-establish IPsec site-to-site tunnels with matching phase-1/phase-2 parameters; migrate remote access to OpenVPN or WireGuard.
Why order and cleanup rules matter most
Two things trip up a Check Point rebuild more than anything else. The first is rule order. Check Point evaluates its rule base top-down and stops at the first match, and OPNsense does the same per interface, so relative position is load-bearing. A specific deny that sat above a broad permit must keep that position, or a rule you thought blocked something quietly stops firing because a later permit now sees the traffic first. The second is the cleanup rule. Check Point’s explicit cleanup rule and OPNsense’s implicit default-deny inbound express the same intent, but you want it visible: add an explicit logged block at the bottom of each interface so the “drop all” is something you can see and audit rather than an assumption. Translate rules in the same sequence the export lists them, and re-check order after you finish, because it is easy to append a rule in the wrong place during a long rebuild.
Carrying over VPNs and threat prevention
Rebuild each Check Point IPsec site-to-site tunnel under VPN, IPsec with phase-1 and phase-2 parameters matched to the peer exactly; encryption, hash, DH group, and lifetimes all have to line up or the tunnel negotiates and then drops. Where Check Point terminated remote-access clients, move those users to OpenVPN or, preferably, WireGuard, which is smaller and quicker to stand up. For the threat-prevention function you were licensing as blades, enable Suricata under Services, Intrusion Detection. Start in IDS (alert-only) mode on the WAN and inter-segment paths, tune out the false positives from your chosen ruleset, then switch to IPS blocking once it is quiet. Suricata covers signature-based detection, but it does not reproduce the full Check Point Threat Prevention blade suite, so validate that the detection you actually rely on is present before you retire the gateway.
Validate before you trust it
- Interfaces and VLANs must be mapped exactly, a wrong VLAN tag silently blackholes a segment.
- Run in parallel. Stand OPNsense up alongside the Check Point gateway and cut over one segment at a time, watching the firewall live logs (and Suricata if you enable IPS) for unexpected drops or passes.
- Test the deny path, not just the allow path. Confirm that traffic which should be blocked is blocked, a rebuild that only verifies connectivity can quietly be too permissive.
- HA early. If the segment needs it, configure CARP failover and test a node loss before go-live, not after.
Gotchas worth flagging
- No central manager by default. Managing many OPNsense boxes means config backups and something like Ansible or the central management plugin, plan the operational model, or you trade license cost for sprawl.
- Throughput and IPS sizing. pf + Suricata is CPU-bound; size hardware for your real throughput with IPS enabled, not the datasheet.
- Logging/SIEM. Re-point firewall logs to your SIEM; the log format changes, so update parsers and dashboards.
The honest summary
Check Point → OPNsense removes per-gateway and per-blade licensing, but you earn the savings by rebuilding the policy by hand and accepting a smaller feature surface. Scope it per segment, recreate objects before rules, map NAT and VPN deliberately, and cut over one segment at a time while watching live logs, testing the block path as carefully as the allow path. Where you need central multi-site management or the full threat-prevention suite, keep Check Point there and use OPNsense where its simpler model is a fit.