Migrating to the UniFi Zone-Based Firewall without breaking your network

The reason real migrations surprise people is that the legacy firewall leaned heavily on implicit behaviour — return traffic that was simply allowed, intra-LAN traffic that flowed by default, VPN traffic that landed wherever it landed. The zone-based model re-expresses everything as explicit source-zone-to-destination-zone policies. The automatic migration does a reasonable job of preserving the rules you wrote down; what it cannot reliably preserve is the behaviour you were getting for free.

That is the through-line for every breakage below. The migration is genuinely “functionally identical” for the explicit rules you authored, and genuinely surprising for the implicit allows you never had to think about — VPN reachability, multicast discovery, cross-VLAN defaults. If your network depends on any of those (and most do), assume they need to be re-checked and, often, re-stated explicitly after you migrate.

These are not hypotheticals; each is a documented, repeatedly-reported failure mode.

• Site-to-site VPN (IPsec / Azure). In one detailed report, after migrating, a remote Azure VPN could no longer reach resources on the upgraded UniFi network: a location still on the old firmware could ping into the upgraded network, and a VM in Azure could ping the old network, but the migrated network stopped responding — traffic that worked before the migration was now dropped.³ The cause is the VPN-zone-to-Internal-zone policy not carrying the implicit allow the legacy rules had. The fix is an explicit policy permitting the VPN zone into the internal network (with return traffic), but you will only know to add it if you test the VPN immediately after migrating.
• Remote-VPN defaults flip — in both directions. Under the legacy firewall, a remote VPN such as Teleport reaching the default network was blocked unless you added a rule. Under ZBF, the VPN zone carries a default Allow-All, so that same traffic can become allowed by default — a security loosening worth checking — even as other VPN networks fail to land in the VPN zone as expected and break.³ The net is that VPN behaviour after migration is inconsistent: some access opens up, some breaks. Verify every VPN, remote and site-to-site, before you trust it.
• Cross-VLAN smart-home discovery (mDNS / multicast). Home Assistant, Sonos, AirPlay and Chromecast, Matter and HomeKit all depend on mDNS/multicast crossing VLANs, and the migration can sever it.⁵ One operator migrated ZBF on a production network and lost access to Home Assistant devices and laptops, with logs reporting traffic blocked “due to a deleted firewall rule”; guesswork and a reboot didn’t fix it.³ Others lost Sonos and casting across VLANs entirely until they rebuilt the right policies.³⁸ The fix lives in three places: Settings → Networks → Multicast Settings (enable mDNS / IoT Auto Discovery for the relevant networks), explicit zone policies with Auto Allow Return Traffic, and — per smart-home specialists — turning IGMP Snooping off, because UniFi’s aggressive implementation tends to drop the very discovery packets HomePods, Apple TVs and Matter devices rely on.¹⁰
• Inter-VLAN isolation surprises. Confirm your segmentation still does what you think rather than assuming it carried over. In one field report, an isolation anomaly — IoT devices reachable from the main LAN — surfaced right after a UniFi OS / Network update; a UniFi support tech traced it to a stale legacy firewall rule that had survived the update and recommended migrating to the Zone-Based Firewall to re-establish clean per-zone isolation.⁹ Separately, there’s a well-known gotcha that looks like broken isolation but isn’t: you can still ping a gateway IP from another VLAN even with inter-VLAN traffic blocked, because that gateway address lives on the same interface. That is expected behaviour, not a leak — but if you don’t want other VLANs reaching the gateway at all, you have to add an explicit policy blocking those VLANs from the Gateway zone (carefully: over-blocking the Gateway zone takes down DHCP and DNS).³²
• Leftover rules you can’t delete. The conversion can leave duplicate or orphaned legacy entries — operators report being unable to remove an old WAN rule or a stale custom rule after migrating, alongside now-redundant Allow/Block policies that need cleaning up once the dust settles.⁷⁶

Do every one of these before you enable the Zone-Based Firewall.

1. Take a full configuration backup — and verify it. Download a System/Config backup (Settings → Control Plane → Backups), confirm the file actually downloads and is sensible, date it, and keep it off the device. This is your only rollback; treat it the way we treat the pre-firmware backup in our update-cadence guide.¹²
2. Snapshot the host. If your controller is a VM or a self-hosted instance, take a hypervisor snapshot as well.
3. Document the current state. Export or screenshot your firewall and traffic rules, your VPNs (site-to-site and remote), your port-forwards, and your intended inter-VLAN access. You cannot verify “functionally identical” actually held if you have no record of what “identical” was.
4. Inventory the implicit-allow dependencies. List everything that relies on traffic you never explicitly permitted: site-to-site and remote VPNs, mDNS/multicast across VLANs (Home Assistant, Sonos, casting, Matter), NAS and printer discovery. These are your test cases for after the cutover.
5. Confirm hardware and version. Make sure you’re on a UniFi OS gateway running Network 9 or later — ZBF needs it and the legacy USG can’t do it — note your Network version (paths and behaviour differ between releases), and check that you aren’t migrating in the middle of a known firmware issue.³¹¹
6. Schedule a window with someone on-site. A firewall migration that goes wrong can lock you out of remote management — exactly the scenario our management-plane hardening guide warns about.¹³ Do it when someone can reach the console locally.

Trigger the migration from Security → Traffic & Firewall Rules → Upgrade — that is the one-click conversion step Ubiquiti documents.¹ Afterwards, zones and policies live under a path that depends on your Network version — Settings → Policy Engine → Zones on 9.3, Settings → Zones or Settings → Policy Table on 9.4, changed again in later releases — so check your build.²³ Then test deliberately, in descending order of “how badly it hurts if it’s broken”:

1. Your own access and remote management — confirm you haven’t locked yourself out.
2. VPNs — site-to-site and remote. This is the Azure case; it is the one most likely to be silently broken and least likely to announce itself.
3. Cross-VLAN smart-home / mDNS — Home Assistant, Sonos, casting, HomeKit. Walk the actual devices, not just a ping.
4. Inter-VLAN isolation — verify the segments that are supposed to be blocked actually are.
5. Port-forwards and public services — confirm anything inbound still resolves.

Fix gaps with explicit zone policies — source zone to destination zone, Allow, with Auto Allow Return Traffic where the return path isn’t already permitted — and use the Multicast Settings for mDNS rather than trying to hand-write multicast rules.²¹⁰ Only once the network is verifiably healthy should you clean up the duplicate and redundant policies the migration left behind.

If the migration breaks something you can’t fix in a few minutes, do not fix-forward by guessing. The supported recovery is to restore the pre-migration backup — which is precisely what operators did after losing Home Assistant access and finding that re-adding rules by guesswork and rebooting changed nothing.³ When the policy set is unfamiliar and has ballooned to roughly a hundred entries, blind rule-adding is slow and error-prone; a clean restore is faster, safer, and gets the network back to a known-good state from which you can plan a calmer second attempt.

Depending on timing, a full rollback can also mean returning the Network application to its pre-migration version — some operators have rolled a controller back to an older release as part of recovering.³ Keep the version-and-backup pairing in mind: the backup restores your configuration, and matching it to the version it came from avoids surprises. All of which is academic if you skipped step 1 of the checklist — without that backup, there is no clean undo, only a rebuild.

The operators who migrate smoothly treat ZBF as a chance to redesign their segmentation, not to recreate their old rule list one entry at a time.

• Don’t create a zone per VLAN. A common self-inflicted wound is spinning up a zone for every network; IoT is just another internal VLAN, and over-zoning multiplies the policy surface for no benefit.⁸³
• Start from a small, sane zone model. A pattern experienced operators recommend: keep the default Internal zone and default network for UniFi and management gear; use the DMZ zone for public-facing servers and the Hotspot zone for guests; then create a Trusted zone (users, internal servers) and an Untrusted zone (IoT, isolated cameras), and allow Trusted → Untrusted with return traffic plus a few specific pinholes for the flows that genuinely must cross.⁸
• Lean on the model’s strength. Policies between zones — not per-interface rules — are the whole point; using that gives you a clean, legible policy set instead of a hundred migration artifacts to maintain.
• Mind the Gateway zone. Blocking traffic to the Gateway zone can take down DHCP and DNS, and deleting a custom zone deletes all of its policies — double-check both before you click.²

• The UI and behaviour are moving targets. Menu paths and some defaults have shifted across Network 9.0 → 10.x, and Ubiquiti has continued to refine both the migration and the zone UI across releases. Verify paths and behaviour against your current version, and treat any step-by-step — this article included — as version-approximate.²³
• “Can’t revert” means no in-product toggle, not “no way back.” The backup-restore path works; that is the entire reason the checklist leads with it.³
• Most migrations are uneventful. Plenty of small networks flip ZBF with no drama. The breakages cluster around VPNs, multicast/smart-home, and heavily-segmented networks — so the more VLANs, VPNs and custom rules you run, the more this matters and the less you should wing it.³
• Hardware and version availability vary. ZBF needs a modern UniFi gateway, and some newer hardware has shipped on older Network versions without it; confirm support before you plan a date.³¹¹
• The mDNS guidance is current shape, not permanent recipe. Multicast and IGMP behaviour and the right toggles have shifted across releases; enabling mDNS per network and reconsidering IGMP Snooping is today’s answer, not a fixed one.¹⁰
• Forum reports are field experience, not vendor specification. The breakage anecdotes here are real, detailed and consistent across independent users, but your exact outcome depends on your rules, VPNs and version — which is the whole argument for testing against your own network rather than trusting a list.

None of this changes the headline. The Zone-Based Firewall is worth migrating to, the conversion mostly takes care of itself, and the difference between a ten-minute job and a lost weekend is entirely upstream of the click: back up first because it is your only undo, write down what you have so you can prove it still works, test the VPNs and the multicast before you walk away, and design the zones rather than transliterating your old rules.