The AVM Fritzbox is ubiquitous in German small and mid-sized businesses — and rightly so. It is reliable, well documented and excellent for home use and small offices with a handful of devices. But as soon as a company grows, connects multiple sites, needs a proper VLAN design or has regulatory demands on the firewall, the Fritzbox hits its limits.
In this article we show at which points you should plan the switch, which hardware makes sense for an OPNsense appliance and how to run the migration in parallel operation without a real maintenance window.
Five Tipping Points: When the Fritzbox Is No Longer Enough
We encounter the following requirements regularly at DATAZONE customers — and they are the classic triggers for the switch:
1. Multiple VLANs with real separation. The Fritzbox knows only two separated networks: LAN and guest. Anyone wanting to separate servers, clients, VoIP, printers, IoT and guest Wi-Fi from each other cannot model this on a Fritzbox. Managed switches expect 802.1Q trunks from the firewall, and OPNsense provides them natively.
2. Fine-grained firewall rules. The Fritzbox allows only simple port forwarding and rudimentary parental-control rules. A real firewall policy following deny-by-default, with rules per source and destination segment, with time windows, GeoIP filtering or rate limiting, is not possible. OPNsense brings the full pf ruleset including aliases, schedules and per-rule logging.
3. VPN concentrator with scalable access. The Fritzbox supports IPSec and, since recent versions, WireGuard. But managing 20+ remote users, site-to-site tunnels with BGP, split-tunneling policies or certificate-based OpenVPN rollouts is not practical with it. Anyone consolidating home office, field service and a second site needs a real VPN concentrator.
4. MDM-ready segmentation. As soon as a mobile-device-management platform such as Intune, Kandji or Jamf is in play, or a SIEM/EDR is watching the endpoints, the network must deliver client isolation, a defined onboarding VLAN and dynamic assignment via RADIUS/802.1X. The Fritzbox knows nothing of 802.1X — so you would need a dedicated RADIUS/NAC in parallel. OPNsense integrates cleanly with FreeRADIUS or an external NAC.
5. SNMP, NetFlow and central monitoring. For an RMM or monitoring system — Zabbix, Checkmk, LibreNMS or our DATAZONE Control — firewall, switches and access points must deliver data via SNMP or NetFlow. The Fritzbox offers only a rudimentary TR-064 interface and no SNMP. OPNsense supports SNMPv3, NetFlow v9 and IPFIX out of the box.
OPNsense vs. Fritzbox: Feature Comparison
| Requirement | AVM Fritzbox 7590 / 7690 | OPNsense 25.7 |
|---|---|---|
| VLANs (802.1Q) | No trunk, only LAN + guest | Unlimited, native trunk ports |
| Firewall rules | Port forwarding, parental control | Full pf ruleset, aliases, schedules |
| VPN site-to-site | IPSec (1 tunnel practical) | IPSec, WireGuard, OpenVPN, multiple tunnels |
| VPN road warrior | WireGuard, MyFritz | WireGuard, OpenVPN, IPSec/IKEv2, SAML |
| RADIUS / 802.1X | No | FreeRADIUS plugin, RADIUS client |
| SNMP monitoring | No (only TR-064) | SNMPv3, NetFlow v9, IPFIX |
| IDS / IPS | No | Suricata with ET Open / ET Pro |
| Multi-WAN / failover | No (only LTE backup) | Multi-WAN, policy routing, gateway groups |
| High availability | No | CARP failover active/standby |
| Logging / reporting | Rudimentary | Full, exportable, ELK-ready |
The Fritzbox remains unbeatable in one area: as an all-in-one device for home office and micro-offices with integrated DSL or fibre modem, telephony and DECT. As soon as a company runs its own VoIP system, managed Wi-Fi and a dedicated modem, this calculation flips.
Hardware Recommendations for the OPNsense Appliance
The hardware depends on WAN bandwidth, number of VLANs and IDS/IPS usage. For 2026 we recommend three classes:
Small — up to 1 Gbit/s WAN, 5–25 users, no IDS Deciso DEC697, Protectli VP2420 or a comparable fanless system with Intel N100 / N305, 8 GB DDR4, 128 GB NVMe, 4× 2.5 GbE Intel i226. Enough for most trades, law firms and agencies.
Medium — up to 2.5 Gbit/s WAN, 25–100 users, with Suricata IDS Deciso DEC2752 or a custom build on Intel Xeon E-2314 / E-2378, 16 GB ECC RAM, 240 GB NVMe, 6× 1 GbE plus 2× 10 GbE SFP+. Enough headroom for Suricata rulesets and traffic shaping.
Large — 10 Gbit/s WAN, > 100 users, HA cluster, VPN concentrator Deciso DEC3852 in a CARP cluster or a Supermicro platform with Xeon Silver 4310, 32 GB ECC, 480 GB NVMe RAID1, 4× 10 GbE SFP+. For multi-site environments with BGP and several hundred WireGuard peers.
Important in every class: Intel NICs (i210, i225/i226, X710, X550-T2). Realtek chips can lead to packet loss and CPU overhead under FreeBSD — one of the most common mistakes in self-built boxes. ECC RAM is mandatory from the medium class upwards.
Migration in Practice: Parallel Operation Without Downtime
A hard rip-and-replace migration is rarely needed. We typically proceed in five steps:
Step 1 — Set up OPNsense behind the Fritzbox. The new OPNsense appliance is connected to a LAN port of the Fritzbox and receives an address via DHCP. On the Fritzbox we configure it as “exposed host” or set up a dedicated port forward to the OPNsense WAN address. This lets us configure all VLANs, firewall rules, DHCP scopes and VPN access in peace, without affecting production users.
Step 2 — Prepare the managed switch. The central switch gets a VLAN trunk to the OPNsense plus the access ports for the new VLANs. Until the cutover, the old access ports stay in the “old” network on the Fritzbox — the switchover happens port by port.
Step 3 — Migrate test users. One or two test workstations are moved to the new OPNsense VLANs. In this phase we check DHCP, DNS, printer reachability, SMB shares, VPN and internet access. Errors in firewall rules surface now, not at go-live.
Step 4 — WAN cutover. Once all VLANs work, the WAN line is moved from the Fritzbox to the OPNsense. For fibre this means either direct GPON SFP coupling, or the Fritzbox stays in front as a pure modem in bridge mode. For DSL, a Draytek Vigor 165 or a Zyxel VMG can serve as a modem-only device. This cutover night is the only real maintenance window.
Step 5 — Retire the Fritzbox or keep it as a phone system. The Fritzbox can live on as a pure DECT/VoIP device in the management VLAN — that saves existing handsets and the integrated phone system. Anyone migrating telephony to a dedicated platform such as 3CX, STARFACE or Placetel disposes of the Fritzbox properly.
A simple WireGuard road-warrior setup, which we like to build as part of step 1, looks like this on OPNsense:
# /usr/local/etc/wireguard/wg0.conf (excerpt, generated by OPNsense)
[Interface]
Address = 10.0.99.1/24
ListenPort = 51820
PrivateKey = <server-private-key>
[Peer]
# Management laptop
PublicKey = <peer-public-key>
AllowedIPs = 10.0.99.10/32
Rollout to endpoints happens via a QR code in the OPNsense UI — productive per user in under two minutes.
Common Pitfalls
Forgetting the Fritzbox as a DECT island. If the Fritzbox continues to serve as DECT base, it must sit in the correct VLAN and must no longer run an active DHCP server. Duplicate DHCP servers are the most common cause of “internet gone” after migrations.
Migrate MyFritz and Fritz remote access. All remote access that ran over MyFritz DDNS or Fritz VPN must be migrated to OPNsense WireGuard or OpenVPN and rolled out to users again. That is a communication task, not a technical one.
Static routes in applications. ERP and warehouse-management systems sometimes have firewall IP addresses hard-coded, for example for licence servers. These systems must be adjusted before the cutover.
Disable SIP-ALG. OPNsense has no SIP-ALG in the way — the Fritzbox does. Anyone running VoIP phones on the network must check SIP registrations after the move. In most cases VoIP even runs more stably after the switch because the Fritzbox no longer manipulates the SIP packets.
Conclusion
The Fritzbox is an excellent consumer device and, for many SMBs, the right starting point. But as soon as multi-VLAN, real firewall policies, a VPN concentrator, MDM-ready segmentation or SNMP monitoring are required, the switch to OPNsense is due — and with the parallel operation described above it is feasible without any real downtime risk. Hardware costs for an SMB-grade setup usually land between 800 and 2,500 euros; the software itself is open source.
DATAZONE supports you in planning and migrating from the Fritzbox to OPNsense: hardware selection, VLAN design, firewall rules, VPN rollout and operations. Contact us — we handle the switch in parallel operation, with no downtime for ongoing business.
More on these topics:
More articles
pfSense Plus vs. OPNsense 2026: Current Feature Comparison
pfSense Plus vs. OPNsense 2026 technical comparison: WireGuard, Zenarmor, HAProxy, Suricata, MFA and HA -- licensing, community and migration paths.
OPNsense HA with CARP: 3 Real-World Pitfalls
OPNsense HA with CARP in SMB environments: the three most common pitfalls -- config drift, sync-interface saturation and DHCP failover -- with fix procedures.
OPNsense Suricata: Rule Tuning Without False-Positive Floods
Tuning Suricata in OPNsense properly: ET/Open vs. commercial rulesets, threshold and suppression lists, SIEM integration and IOC rules against alert fatigue.