Migrating to OPNsense
A firewall migration rarely fails because of the new firewall. It fails because of forgotten rules, old VPN peers, undocumented exceptions and that one printer that has needed a port forward for years. That is why we start with what you already have.
Process
Five steps, one runbook
-
10 Inventoryjoint cleaned-up target rule set
Configuration export, discussion with your IT team, analysis of rules, NAT, VPNs, certificates and special cases. The hit counters show which rules are actually used.
-
20 Translationaepfel+birnen finished target configuration
Conversion into OPNsense logic: aliases, interface rules, NAT, VPN tunnels, user integration. We map vendor-specific features with built-in tools or plugins.
-
30 Testingjoint approved test reports
Set-up in the lab or in parallel in a test segment. We check critical applications, VPN tunnels and special cases against a shared checklist.
-
40 Cutoveraepfel+birnen OPNsense in production
Cutover in a maintenance window following a runbook. The old firewall stays cabled and ready, and going back takes minutes.
-
50 Follow-upaepfel+birnen complete documentation
Log analysis for blocked legitimate connections, fine-tuning of the rule set, handover of the documentation.
By vendor
Migration by source system
Every vendor has its quirks. Each source system has its own page with a feature mapping.
Inventory
What we record, and where things get stuck
What we record
- interfaces, VLANs, zones and IP plan
- firewall rules with hit counters
- NAT and published services
- site-to-site VPNs with their peers
- remote access VPN, users, 2FA
- DHCP, DNS, NTP, certificates
- web and application filters
- special cases: VoIP, multicast, IPv6, medical devices
Typical pitfalls
- Zone logic: many vendors think in zone pairs, while OPNsense evaluates rules inbound per interface. We translate the logic.
- MTU and MSS with IPsec: we set MSS clamping from the start.
- VPN peers: we agree parameters and timing in advance.
- VoIP and SIP: ALG behaviour differs, so we test telephony specifically.
- Hidden dependencies: hit counters and logs show what is really in use.
Effort
How long it takes
| Environment | Preparation | Cutover |
|---|---|---|
| single site, manageable rule set | a few days | 1–2 hours |
| several sites, VPN mesh | 1–3 weeks | staggered per site |
| HA cluster, data centre, hospital | several weeks | by runbook, often without noticeable interruption |
Result
What you have at the end
The documentation is structured so that another service provider could take over. We want to keep you through quality, not through knowledge only we hold.
Handover
- running OPNsense with a cleaned-up rule set
- network diagram and rule set documentation
- test reports and sign-off
- credentials and emergency procedure
- configuration backup outside the firewall
FAQ
Frequently asked questions
Can we simply import the old configuration?
No, and that is a good thing. Even between pfSense and OPNsense there is no reliable direct import. The structured translation is the opportunity to get rid of legacy clutter.
What happens if something does not work after the switch?
The old firewall stays cabled and ready until sign-off. If in doubt, we switch back within minutes, analyse the issue and try again.
Do our staff need to do anything?
If the VPN technology changes, they install a new client. We provide preconfigured profiles and a short guide.
Contact
How much work will your migration be?
Send us a configuration export and we will give you a reliable estimate of the effort.