Overview
UniFi’s Zone-Based Firewall (ZBF) simplifies rule management by organizing networks into logical zones such as:
- Internal (LAN)
- External (Internet)
- Gateway (the UDM itself)
- VPN
- Hotspot (guest Wi-Fi)
- DMZ
The Hotspot zone is used to isolate and manage guest traffic through dedicated firewall rules. This is essential for captive portals to function correctly.
How Captive Portals Work with Zones
When a guest device connects to a Hotspot-enabled SSID or VLAN, it’s automatically placed in the Hotspot zone. The UniFi gateway intercepts the first HTTP or HTTPS request and redirects it to an external captive portal (like MyPlace).
Zone-Based Firewall — Further Explained
On UniFi gateways running ZBF (Network v9.0+), every rule is Source Zone → Destination Zone. Which zone the controller sits in decides the rule you write:
| Controller location | Destination zone | Rule type |
|---|---|---|
| On the gateway (UDM/CGW) | Gateway | External → Gateway = Internet Local (no port forward) |
| Behind the gateway (Cloud Key) | Internal (LAN) | External → Internal + port forward |
| Behind the gateway (Self-hosted) | Internal (LAN) | External → Internal + port forward |
Two rules of thumb:
- Controller = the gateway → the traffic terminates on the firewall itself, so the zone is Gateway, and a port forward makes no sense (there’s nothing to forward to).
- Controller = a device behind the gateway → traffic must cross through to the LAN, so you need both a External → Internal ZBF Allow rule and a port forward. The port forward sets the destination; ZBF decides whether it’s permitted.
Each section below states the exact zone rule for that case.
1. UDM / UDM Pro / UDR / Cloud Gateway
The controller is built into the gateway, so traffic to its UI is Internet → Local — destination zone Gateway, not a forward to an internal host. This is an Internet Local rule in Zone-Based Firewall terms.
Method A — Remote Access (recommended)
- Settings → System → Advanced → Remote Access → enable, link Ubiquiti SSO.
- Access via unifi.ui.com or the mobile app.
No inbound ports opened. If you only need to reach the UI, stop here.
Method B — Direct access via ZBF (Internet Local rule)
Step 1 — allowlist (IP Group) Settings → Profiles → IP Groups → create admin-allowlist → add your external IP(s)/subnet.
Step 2 — firewall policy Settings → Security → Firewall → Create Policy
| Setting | Value |
|---|---|
| Source Zone | External |
| Destination Zone | Gateway |
| Source | IP Group admin-allowlist (NOT Any) |
| Destination Port | 443 (TCP) — or custom UI port |
| Action | Allow |
Place above any Block rule. Save and apply.
UI listens on 443. If 443 conflicts with Ubiquiti remote management, move the UI to a custom port.
2. Cloud Key (UCK-G2 / G2-Plus)
Key difference: the Cloud Key is a UniFi OS console, but it is NOT your gateway — it sits behind whatever router/gateway you have. So you cannot use a Gateway-zone rule; you must port-forward on the upstream gateway to the Cloud Key’s IP.
Method A — Remote Access (recommended)
The Cloud Key is a UniFi OS console, so it supports SSO Remote Access just like a UDM: Cloud Key → System → Remote Access → enable, link SSO → reach it via unifi.ui.com. No ports opened.
Method B — Port forwarding to the Cloud Key
Cloud Key Gen2 / G2-Plus run UniFi OS → UI is on 443. Cloud Key Gen1 (legacy) runs the Network app directly → UI is on 8443.
Step 1 — allowlist your external IP(s) on the upstream gateway.
Step 2 — port forward on the upstream gateway:
- From: Limited → your allowlisted source IP (not Any).
- WAN Port: 443 → Forward to Cloud Key IP, port 443 (or 8443 for Gen1).
Step 3 — Zone-Based Firewall rule (if the upstream gateway is a UDM with ZBF). Port forwarding alone is not enough on ZBF — you also need an explicit Allow:
Settings → Security → Firewall → Create Policy
| Setting | Value |
|---|---|
| Source Zone | External |
| Destination Zone | Internal (the LAN zone the Cloud Key is in) |
| Source | IP Group admin-allowlist (NOT Any) |
| Destination | Cloud Key IP |
| Destination Port | 443 (or 8843 for Gen1) |
| Action | Allow |
Place above any Block rule. Both the port forward (Step 2) and this ZBF rule must be present.
The Cloud Key cannot host a VPN itself — if you want VPN access, it has to run on the upstream gateway.
3. Self-hosted (UniFi Network Application)
Plain software on a server/VM/Docker — not a gateway, not a UniFi OS console. External access is port forwarding on the gateway to the host. Note: self-hosted controllers cannot use Ubiquiti SSO Remote Access (that’s console-only).
Ports
| Port | Protocol | Purpose | External? |
|---|---|---|---|
| 8443 | TCP | Web UI (HTTPS) | Yes — primary |
| 8080 | TCP | Device inform (adopt) | Only for L3/WAN adoption |
| 3478 | UDP | STUN | Only for remote devices |
| 8880 | TCP | Guest portal HTTP | Only for captive portal |
| 8843 | TCP | Guest portal HTTPS | Only for captive portal |
| 6789 | TCP | Mobile speed test | Optional |
| 10001 | UDP | Device discovery | Local only |
For browser management from outside, 8443 alone is enough.
Method A — Port forwarding
Step 1 — allowlist your external source IP on the gateway.
Step 2 — port forward:
- From: Limited → allowlisted source IP (not Any).
- WAN Port: 8443 → Forward to controller IP, port 8443.
Step 3 — open the port in the server’s OS firewall (e.g. ufw allow 8443/tcp).
Step 4 — Zone-Based Firewall rule (if the gateway is a UDM with ZBF). Same as Cloud Key — port forward alone isn’t enough:
Settings → Security → Firewall → Create Policy
| Setting | Value |
|---|---|
| Source Zone | External |
| Destination Zone | Internal (the LAN zone the server is in) |
| Source | IP Group admin-allowlist (NOT Any) |
| Destination | Controller server IP |
| Destination Port | 8443 |
| Action | Allow |
Place above any Block rule.
Method B — Reverse proxy (cleaner)
Put an nginx/Caddy reverse proxy in front with a proper TLS cert and HTTP auth / IP restriction, expose only 443 externally, proxy to 127.0.0.1:8443 internally. Better than exposing 8443 raw — gives you real certs, access logs, and an extra auth layer.
Security (applies to all categories except Remote Access/VPN)
- Source IP allowlist — the single most important control. Don’t publish without it.
- 2FA + strong password on the admin account.
- Keep ports minimal — don’t open 8080/3478 unless you actually need remote adoption.
- Custom UI port reduces scanner noise — but it’s obscurity, not security.
- HTTPS only, keep firmware/controller current.
⚠️ What you could do but shouldn’t
Source: Any — exposes the admin UI to the entire internet. One firmware vuln = full compromise of the router and everything behind it. Don’t, unless there’s no alternative — and even then, use a VPN instead.
Best option for dynamic external IP: VPN
If your external IP is dynamic (so a tight allowlist isn’t practical), do not fall back to Any. Instead run a VPN and reach the controller over its local address:
- UDM / Cloud Gateway: built-in WireGuard — Settings → VPN → WireGuard Server.
- Cloud Key / Self-hosted: run the VPN on the upstream gateway (WireGuard/OpenVPN/Teleport), then access the controller’s LAN IP through the tunnel.
This closes the attack surface entirely and solves the dynamic-IP problem.
Troubleshooting
Port reachability check: from outside via nc -vz <ip> <port> or an online port checker.
Not reachable: verify your real external IP is in the allowlist, the port matches your category (443 UDM/CK-Gen2, 8443 self-hosted/CK-Gen1), and the Allow rule sits above any Block rule.
Devices drop after publishing: don’t touch 8080/3478 unless needed — they’re for inform, not the UI.
443 conflict (UDM): move the UI to a custom port or use Remote Access.
Cloud Key unreachable but forward looks right: check that the upstream gateway’s ZBF also allows the traffic — port forward alone isn’t enough on a UDM.