There is no automated importer from SonicWall to OPNsense, and that is fine, because a firewall migration you do by hand is a firewall migration you actually understand. Teams leave SonicWall for two reasons: the stacked cost of the appliance plus per-service subscriptions (gateway AV, IPS, content filtering, support renewals), and the trust hit from a run of serious CVEs in SonicOS and the SMA line. OPNsense gives you a transparent, open BSD-based firewall on hardware you choose. The work is a deliberate policy rebuild. Do it methodically and you will end up with a cleaner ruleset than the one you left.
Inventory before you build
Export the SonicWall config and turn it into a worksheet first. You are cataloguing:
- Address objects and groups, service objects and groups.
- Access rules, in order, with their source zone, destination zone, action, and any logging or schedule attached.
- NAT policies (the SonicWall split of access rule plus NAT policy is the thing people forget).
- VPN tunnels: site-to-site and SSL-VPN (NetExtender) users.
- Interfaces, zones, and VLAN sub-interfaces.
Intent matters more than literal translation. A rule that exists because of a NAT quirk five years ago may not need to exist at all.
Objects, then rules, in order
Recreate address and service objects in OPNsense first under Firewall, Aliases. Aliases are the direct analog of SonicWall objects and groups, and nesting works. Build these before any rule so rules reference names, not raw IPs.
OPNsense evaluates rules first-match per interface, top to bottom, which differs from SonicWall’s zone-pair matrix. So translate zones into interface groups and preserve rule order carefully. A deny that sat below a permit in SonicWall must keep that relative position. Add explicit block rules with logging at the bottom of each interface so you can see what the default deny catches:
# bottom of LAN ruleset
block in log quick on LAN all # catch-all, then review the logsNAT needs its own pass
SonicWall couples access and NAT; OPNsense separates them. Outbound NAT lives under Firewall, NAT, Outbound (switch to hybrid mode to keep automatic rules and add your own). Inbound services map to port-forward rules under NAT, Port Forward, and OPNsense can auto-create the matching pass rule, but review it rather than trusting it blind. Recreate one-to-one NAT under NAT, One-to-One.
VPNs: pick the modern target
Site-to-site IKEv2 tunnels rebuild as IPsec under VPN, IPsec, phase 1 and phase 2 matching the peer’s parameters exactly. For remote access, SonicWall NetExtender SSL-VPN has no OPNsense equivalent, so move users to OpenVPN or, preferably, WireGuard. WireGuard config is small and fast:
[Interface]
PrivateKey = <server-key>
ListenPort = 51820
Address = 10.10.0.1/24
[Peer]
PublicKey = <client-key>
AllowedIPs = 10.10.0.2/32VLANs and IDS
Recreate VLAN interfaces under Interfaces, Other Types, VLAN, then assign and enable them, mirroring your SonicWall sub-interfaces and tags. For the IPS function you were paying SonicWall for, enable Suricata under Services, Intrusion Detection. Start in IDS (alert-only) mode on the WAN and inter-VLAN paths, tune out the false positives from the ET Open ruleset, then flip to IPS blocking once the noise is gone.
Cut over per segment and test the deny path
Run OPNsense in parallel. Stand it up on a spare interface or second box, replicate the policy, then move one VLAN or segment at a time by changing its gateway. The test that matters most is the negative one: confirm traffic that should be blocked is blocked. It is easy to verify that allowed traffic flows and miss that your catch-all deny never engaged because an earlier permit was too broad. Watch the live firewall log while you probe.
Piloting and per-segment cutover
Resist the urge to swap the whole firewall in one window. Stand OPNsense up in parallel, pick a low-risk VLAN or segment, and move only that one by changing its gateway to the OPNsense interface. Watch the live firewall log and, if you have Suricata enabled, its alerts through a short hypercare period before you touch the next segment. The rollback is deliberately boring: because the SonicWall stays racked and configured, reverting a segment is just pointing its gateway back. That safety net is what lets you move confidently rather than gambling a maintenance weekend on a full replacement. Expand segment by segment only as each one validates under real traffic, and keep the SonicWall in place until the last segment is proven, not until the first one looks fine.
Where SonicWall still wins
Be honest about the gaps. SonicWall ships integrated UTM: gateway antivirus, Content Filtering Service, and managed IPS signatures as a single licensed bundle, which OPNsense approximates with Suricata plus web-proxy plugins that you tune yourself. Central management across many sites via GMS or the cloud console is more polished than wrangling OPNsense boxes individually or through a config-sync setup. And there is a vendor to call. For a one-person shop with twenty branch firewalls, that managed bundle can be worth the renewal.
Before you set a date
SonicWall to OPNsense is a hand-built policy rebuild: aliases, ordered rules, separated NAT, VPNs moved to IPsec or WireGuard, VLANs, and Suricata, validated by a parallel run and a tested deny path. You shed appliance-plus-subscription cost and gain a transparent, auditable firewall, at the price of assembling UTM features and central management yourself. Model the subscription savings against that operational effort in the calculator above before you set a cutover window.