pjhtech Tools
Ubiquiti · UniFi

UniFi Management Ports: Device, Server and Admin Traffic

Before writing a firewall rule, identify the source, destination and service. “Allow the UniFi ports” is too vague for a useful change request. A browser opening the management page and an AP contacting UniFi Network are different flows, even when both destinations run on one appliance.

Scope: UniFi Network device management and UniFi OS/self-hosted management paths. Compact task reference, not the exhaustive port list for all UniFi applications. Feature and server deployment determine which listeners exist. Reviewed 2026-10-08.

This short table covers frequently investigated management services. It is deliberately not an instruction to expose every port to the internet. Use the deployment's actual listener and Ubiquiti's full requirements for optional applications, guest portals and remote management.

Common management flows #

ServiceTransport / destination portEndpoint context
Device-to-Network communicationTCP 8080Managed device reaches Network host
STUNUDP 3478Relevant device/remote-management communication
HTTPS managementTCP 443 or deployment-specific 8443Authorized browser reaches the configured management listener
Device discoveryUDP 10001Adoption/discovery context; not a substitute for routed reachability
SSHTCP 22Authorized administrator reaches the device
DNSUDP/TCP 53Device or host reaches its configured resolver
Time synchronizationUDP 123Device or host reaches its NTP service

“Ingress” in a vendor server table describes traffic entering that server. It does not mean every upstream firewall should accept unsolicited traffic from any source. Translate the entry into your own diagram, including the actual initiating endpoint and the return traffic allowed by a stateful firewall.

Check the service you actually need #

From an authorized Windows management workstation, a TCP test can help distinguish basic reachability from application behavior:

Check the service you actually need
UniFi · Windows PowerShell

Active test

Replace these example values: <network-host>.

Test-NetConnection <network-host> -Port 8080
Active test

Replace these example values: <management-host>.

Test-NetConnection <management-host> -Port 443

A successful TCP handshake confirms a listener was reachable from that workstation. It does not prove the AP can reach it from another VLAN, nor does it validate adoption, credentials or certificate trust. These TCP tests also do not test STUN, DNS over UDP or broadcast discovery.

For a failed adoption, test from the device's management network and correlate with the existing adoption guide. For a browser failure, test the actual management URL and destination port. Do not change the inform destination simply because HTTPS is working: the services have distinct jobs.

Document each required exception as an explicit flow: management VLAN to Network host on TCP 8080, for example. Restrict administrator-only services to the intended management path. A server's internal database port is not a reason to publish its database to managed devices or the internet. If only one optional feature is failing, check that feature's requirements rather than widening the entire ruleset.

Sources

Documentation reviewed: 8 October 2026