UniFi

A guide to choosing, deploying, and integrating UniFi into infrastructure.

Network Stack

The UniFi network stack is the management OS that handles all network devices. Gateways, switches, APs, and more. UniFi has a cloud-hosted option as well as a physical device (called a CloudKey) that handles this for you.

Gateways

Gateways can vary in capabilities containing some or all of the following features:

• Firewall + Routing
• Network Controller Stack
• Suricata IPS, Honeypot
• Integrated WiFi (Hardware dependent)
• Switching (Does each port have full 1/2.5/10GbE capability or is it a shared backplane?)
• Other UniFi Integrations (Protect)

Networking Policies

Subnets, VLANs, Routing, and more.

Firewall Policies

UniFi's firewall policies are somewhat confusing at first, even when exploring via nmap, tcpdump, and other tools. They work differently compared to OpenWrt and pfSense.

Security Policies

UniFi has some interesting security features available that are either baked-in or optional check-boxes.

PORT     STATE SERVICE       REASON         VERSION
21/tcp   open  ftp?          syn-ack ttl 64
22/tcp   open  ssh?          syn-ack ttl 64
23/tcp   open  telnet?       syn-ack ttl 64
25/tcp   open  smtp?         syn-ack ttl 64
80/tcp   open  http?         syn-ack ttl 64
110/tcp  open  pop3?         syn-ack ttl 64
445/tcp  open  microsoft-ds? syn-ack ttl 64
1433/tcp open  ms-sql-s?     syn-ack ttl 64
2222/tcp open  EtherNetIP-1? syn-ack ttl 64
8000/tcp open  http-alt?     syn-ack ttl 64

Administration

Remote management via https://unifi.ui.com/ and the mobile app are invaluable features, with trust being placed in UniFi's infrastructure for these to work. Some "classic" remote admin capabilities are somewhat limited though.

Logging Policies

Logging and alerting on activity. This is where UniFi falls short.

Switches

UniFi Switches are one of the best ways to extend and grow a network as well as reduce power adapters via PoE++ support.

These resources are key if you're appending UniFi switches or APs onto an existing network:

• Understand and Mitigate Network Loops
  • Best Practices for IOT Devices
  • Best Practices for Chromecast and AirPlay

Access Points

One of the most common setups is deploying a UniFi AP behind something like pfSense. In this case you'll need a Network Controller, either a self-hosted container/VM, a local CloudKey device, or a cloud-hosted option with UniFi.

Debug Console

Some APs allow you to acces the debug console. UniFi OS is based on OpenWrt, so many of the commands you'd expect are there to do basic troubleshooting and review of the system.

• UniFi OS UI > UniFi Devices > [Your AP] > Settings (Gear) > Debug
• This will open a small web interface dropping you into a shell
• There's a useful copy button [+] at the top right of this window, so you can dump the text into a text editor for review

# This will dump all wireless interface information
iw dev

Travel Router

The UniFi Travel Router is an interesting and fun device. Assessing how this device performs and works will be documented here.

As a final note, while it's an unreasonable ask, the option to continually scan for and attempt to connect to OPN / OWE networks would be interesting for on-the-go use.

Setup

The device setup is easy. The default WiFi network it spins up cannot be auto-joined, and does not appear to have a known hard-coded credential. Once you take ownership of the device through one of the methods below, you can configure it and it's "yours". The easiest and best way to do this is via the UniFi mobile app over Bluetooth.

• UniFi Network App + Bluetooth
• LAN / USB + management interface

Portability

It's portable. It may not be clear from the marketing material but it's tiny, and lightweight. The specifications are available on the store page, but for anecdotal comparison:

• 2/3 as long as the latest model iPhones, similar width and height
• Same length as a FlipperZero, half the height, and 1.5x the width
• 1/2 as tall as the Pineapple Pager, similar width and length
• Feels about as heavy as a FlipperZero

Performance

In my testing, the Travel Router was on a different floor, connecting to a WiFi 7 capable AP, over 5 GHz. It's less than 100' or 30m away if you were to draw a direct line between the two devices in space.

The results show it did generally get within range of what connecting directly to WiFi would provide. The low upload over Teleport may be due to the network configuration there, but this table will be updated as it's tested across more environments.

Averages are rounded for simplicity.

One thing that stands out as missing, is you can't set the Travel Router's WiFi band to either 2.4 or 5 GHz specifically, it seems to default to 2.4 for some reason. I connected to an SSID that only advertised on the 5 and 6 GHz bands, and the router still set its own AP to 2.4 GHz.

It's also worth mentioning, without an internal battery, it always needs connected to a power source. If you use your phone as a power source, it will consume the battery very quickly, usually within 4-6 hours on most modern phone models as of early 2026.

Security

DNS being one of the critical pieces to securing your internet usage, it's disappointing to see the Travel Router has no dedicated options to enforce DNS over TLS or HTTPs. What you can do is enforce a specific DNS server via the DHCP options, such as 1.1.1.1 and 9.9.9.9, but this is all clear text. Below is a query made from a client directly to the Travel Router's WiFi DNS listener, and that request captured on the upstream gateway and network it was forwarded across.

$ dig @10.10.10.1 kali.org +short
104.18.5.159
104.18.4.159

$ sudo tcpdump -n -vv -i vlan0.10 -Z nobody 'host 192.168.10.49 and (port 53 or port 853)' | grep -iE "kali.org"
dropped privs to nobody
tcpdump: listening on vlan0.10, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    192.168.10.49.36545 > 9.9.9.9.53: [udp sum ok] 12345+ [abc] A? kali.org. ar: . OPT UDPsize=1234 [COOKIE <redacted>] (56)
    192.168.10.49.36545 > 1.1.1.1.53: [udp sum ok] 12345+ [abc] A? kali.org. ar: . OPT UDPsize=1234 [COOKIE <redacted>] (56)
    1.1.1.1.53 > 192.168.10.49.36545: [udp sum ok] 12345 q: A? kali.org. 1/2/3 kali.org. A 104.18.4.159, kali.org. A 104.18.5.159 ar: . OPT UDPsize=1234 (56)
    9.9.9.9.53 > 192.168.10.49.36545: [udp sum ok] 12345 q: A? kali.org. 1/2/3 kali.org. A 104.18.4.159, kali.org. A 104.18.5.159 ar: . OPT UDPsize=123 (45)

What else is listening on the device? The network interfaces themselves are reasonably secure, only exposing port 53 on both the LAN and "WAN" side.

nmap -n -v -Pn -sT -p- --reason --packet-trace -e wlan0 --open -T4 10.10.10.1
# SNIP
CONN (9.2310s) TCP localhost > 10.10.10.1:31081 => Connection refused
CONN (9.2310s) TCP localhost > 10.10.10.1:48539 => Connection refused
CONN (9.2310s) TCP localhost > 10.10.10.1:27851 => Connection refused
CONN (9.2322s) TCP localhost > 10.10.10.1:15352 => Connection refused
CONN (9.2322s) TCP localhost > 10.10.10.1:39363 => Connection refused
CONN (9.2322s) TCP localhost > 10.10.10.1:33604 => Connection refused
Completed Connect Scan at 01:23, 9.22s elapsed (65535 total ports)
Nmap scan report for 10.10.10.1
Host is up, received user-set (0.046s latency).
Not shown: 65534 closed tcp ports (conn-refused)
PORT   STATE SERVICE REASON
53/tcp open  domain  syn-ack

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 9.24 seconds

nmap -n -v -Pn -sT -p- --reason --packet-trace -e wlan0 --open -T4 192.168.10.49
# SNIP
CONN (59.6083s) TCP localhost > 192.168.10.49:20737 => Connection refused
CONN (59.6087s) TCP localhost > 192.168.10.49:20147 => Operation now in progress
CONN (59.6095s) TCP localhost > 192.168.10.49:5387 => Connection refused
CONN (59.6097s) TCP localhost > 192.168.10.49:8122 => Connection refused
CONN (59.6135s) TCP localhost > 192.168.10.49:20147 => Connection refused
Completed Connect Scan at 01:23, 59.41s elapsed (65535 total ports)
Nmap scan report for 192.168.10.49
Host is up, received user-set (0.0035s latency).
Not shown: 65528 closed tcp ports (conn-refused), 6 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT   STATE SERVICE REASON
53/tcp open  domain  syn-ack

Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 59.83 seconds

It's odd that port 53 is even listening on the "WAN" side, but it does not respond to DNS queries.

$ dig @192.168.10.49 microsoft.com +short
;; communications error to 192.168.10.49#53: timed out
;; communications error to 192.168.10.49#53: timed out

$ nc -nv 192.168.10.49 53
Connection to 192.168.10.49 53 port [tcp/*] succeeded!

$ nc -nuv 192.168.10.49 53
Connection to 192.168.10.49 53 port [udp/*] succeeded!

That covers an initial review and assessment of the UniFi Travel Router. More notes will be added over time.

Protect Stack

NVRs

Unless you are a medium to large scale operation requiring numerous cameras and 24/7 video storage for compliance reasons, the entry-level UNVR-Instant is the best way to get started with the UniFi Protect stack.

• Each port is PoE to support the connected devices (cameras or superlink)
• One internal HDD is completely fine if you configure recordings to be based on events rather than 24/7
• Automatically gives you full Protect application access via the mobile app and UniFi's backplane for end-to-end encrypted remote access

AI processing can be done on-device depending on the camera, so you do not need anything other than the UNVR-Instant and any additonal cameras or sensors you might need for your business or home.

All NVR's past the UNVR-Instant jump sharply into medium / large scale territory with numerous storage bays and the need for separating all of the features and capabilities out amongst other devices in your network infrastructure, namely ports and PoE to the protect devices need to be handled by other gear. These NVR's are purely for storage, and will require additional investment to tie everything together.

SuperLink

This can be PoE powered via a UniFi switch or the UNVR Instant, and is managed through the Protect application. All SuperLink connected devices use the same IP as the SuperLink, so if you're locking down clients in the NVR / IOT subnet by MAC address, you only need to scope the SuperLink's MAC into your DHCP server.

The SuperLink SubGHz protocol will go up the 2km with full line-of-sight, and through numerous walls, floors, and other paths within a normal building or floor.

More review of this protocol will need to be done.

USL-Sensors

This includes door, window, motion, and other environmental sensors. Adopt them via the Protect application (mobile or web) and configure them from there. Naming them based on their location and function makes them easy to review in the web and mobile applications.

Integrating & Deploying

TODO

Managing

Web Interface

The UniFi Network and UniFi Protect (camera / NVR) stacks have separate interfaces and mobile applications. All hardware and self-hosted Network servers can be accessed and managed locally via an IP on one of their interfaces, or more securely via the https://unifi.ui.com/ backplane.

Mobile Applications

The mobile applications provide visibility to all of your UniFi ecosystem natively, and the convenience is a huge selling point. The main difference with these apps of course is the level of detail you can get into. It's fairly deep, but you don't have absolutely every configuration feature available that you might in the web interface.

Troubleshooting

TODO