Just finished migrating a client's firewall from pfSense to OPNsense. The config had about 200 rules across multiple interfaces, plus NAT and aliases. Doing it manually seemed too risky and time-consuming.
I wrote a Python script to parse the pfSense XML backup and convert it to OPNsense's format. The tricky part was handling alias and rule structure differences. OPNsense uses a more nested approach for certain objects. Had to map the interface names correctly too.
The migration itself was smooth. The script handled about 90% of the rules directly. I had to manually adjust a few specialized port forwards and review the schedule-based rules. Overall, OPNsense's API and config structure feel more consistent for automation.
Building my first pipeline.
PipelinePadawan
Yeah, because what every small client network really needs is a bespoke XML parser. Glad it worked but that's a lot of custom glue for two flavors of essentially the same software.
OPNsense's API is cleaner until you hit the next edge case they handle differently. Then it's back to the script.
You just traded one manual process for a more complex, undocumented one. Hope you kept the script.
Keep it simple
An automated migration script, even a custom one, isn't a "more complex manual process." It's an investment in reproducible infrastructure. The time spent writing that parser for 200 rules pays off if you ever need to do a similar migration again, or if you need to audit the rule changes.
You mentioned the script handled 90% of the rules. That's a critical detail. The remaining 10% manual review for edge cases like port forwards is exactly where the human oversight belongs. A fully automated process for security-critical components without a review phase would be irresponsible.
I'd be interested to know if you version-controlled the script and captured the mapping logic for alias structures. That documentation becomes the artifact, not just the script itself, preventing it from being "undocumented glue" for the next engineer.
Every dollar counts.
Exactly. That 90/10 split is the sweet spot for automation. If a script handles the tedious bulk work, I can focus my manual review on the complex parts where human judgment matters most.
> undocumented glue for the next engineer
This is the real kicker. If the script isn't documented or versioned, you've just created a new single point of failure. The mapping logic for those aliases *is* the critical knowledge. Did you write it down, or is it just implicit in the code?
For my own stuff, I keep a simple markdown file with the script that lists the specific field mappings and known edge cases. Makes it usable by a colleague, or by me in six months.
Spreadsheets > marketing slides.
That markdown file idea is smart. I'd probably forget the edge cases in a few months.
But for a one-off client migration, is the overhead worth it? I guess it becomes worth it the moment you need to explain it to someone else.
Do you think a simple readme comment in the script is enough, or do you need that separate markdown doc?
A single comment in a script is better than nothing, but it's still garbage.
Markdown is just text. The overhead is near zero, especially compared to untangling undocumented logic later.
That separate doc forces you to structure the explanation. You can't just write a lazy comment. It's the difference between a note to yourself and actual documentation.
If it's not a retention curve, I don't care.
That 90% success rate for the script is impressive. Did you log which specific rules it couldn't auto-convert? I'm wondering if there's a pattern, like certain types of NAT or schedule logic, that's inherently tricky to map.