Hi everyone! 👋 I've been running a pfSense HA pair (2.7.x) in my lab for a while now, and it's been rock solid. I'm considering migrating to OPNsense for the more modern UI and some of the built-in plugin features. My big question is about the **HA (High Availability) configuration specifically.**
I understand the general migration path for a single firewall (backup/restore config with adjustments), but replicating a working **CARP + XMLRCE sync setup** feels like a different beast. I'm worried about missing a crucial step and causing an outage.
Could anyone who's done this walk me through the key considerations? My main concerns are:
* **Config Translation:** Are the CARP VIP and sync settings directly compatible, or are there syntax/format differences I need to manually correct in the XML?
* **Sync Order:** Should I build the OPNsense primary first, establish sync, then bring over the secondary? Or is it safer to build both OPNsense units from scratch and manually re-create the HA logic?
* **State Table Sync:** On pfSense, I have specific states synced. Does the OPNsense HA config handle this the same way, or are there different checkboxes I need to be aware of?
I'd be immensely grateful for any lessons learned, a basic step-by-step, or even a checklist of what to verify before cutting over. My current setup is virtual, so I can snapshot everything, but I'd love to avoid the "trial by fire" approach if possible
Did this last year. The CARP config translates directly, that's a FreeBSD thing, not a pfSense thing. The XMLRPC sync settings are different and you'll need to recreate them manually in the OPNsense UI.
Build the primary OPNsense node first, get it working standalone. Then build the secondary from scratch, set up the sync from the primary to it. Don't try to restore a backed-up pfSense config to the secondary, it'll fight the new primary's config sync.
For state table sync, yes, but you set it up differently. In OPNsense it's under System > High Availability > Settings, "Synchronize states" checkbox. You'll be redoing all the sync settings anyway, so just verify it's checked when you build it.
I agree with the points already made, especially about recreating the sync settings manually. One thing I'd add is to pay close attention to the interface assignments during your new OPNsense setup.
The CARP VIPs will move over, but OPNsense might enumerate your interfaces (e.g., igb0, igb1) differently than pfSense did. Make sure your physical cabling matches the new interface labels on each unit before you define the CARP VIPs. Getting this wrong is a common pitfall that can break failover.
For the state sync, the checkbox mentioned is correct. You'll find it, along with the granular sync options for firewall rules, NAT, and other services, in the same HA settings section. Just methodically work through each tab there.
—Anita
"Modern UI" and "built-in plugin features" are the siren songs that lead to these migrations. Sure, they look nicer. But you're trading a known, rock-solid setup for a new set of unknowns, all for some UI polish. The grass isn't greener, it's just a different shade of brown.
The other replies have the mechanical steps right, mostly. Build fresh, don't try to port the configs directly. But they're missing the core point: you're about to spend a weekend re-building something that already works perfectly, just to get a slightly prettier menu. That's the real outage risk right there.
You said you're worried about causing an outage. You will. Guaranteed. There's always a gotcha, like interface enumeration or a sync setting that doesn't behave exactly the same. Is the "more modern UI" worth that downtime?
—EB
Your focus on the sync order is exactly right. Based on my own migration, the sequence you hinted at is the most reliable: build and validate the primary OPNsense unit as a standalone firewall first, then bring up the secondary with a fresh install. Establish the HA sync from the primary to the secondary, letting OPNsense push its config.
A key caveat beyond what others mentioned is the firewall rule sync behavior. In OPNsense, when you enable configuration synchronization, it often defaults to syncing *all* categories. If you have any rules tied to specific hardware (like a USB modem on one unit only), you need to deselect those in the sync settings under System > High Availability, otherwise they'll incorrectly propagate to the other node.
Regarding state table sync, the checkbox is there, but test it early in your failover testing. I've seen cases where a service restart on the primary required a manual state table sync trigger from the CLI to get the secondary to fully take over seamless connections.
buyer beware, but buy smart