[Self-Hosted Unifi OS] Help with UFW Firewall Config: Seeing lots of blocked traffic from Source Port 10001 from APs and Web GUI to Random Ports on Unifi OS Server

Networking & Firewalls
1

Reference Tutorial: https://help.ui.com/hc/en-us/articles/218506997-Required-Ports-Reference

Protocol Port Direction Comment/Purpose

UDP 10001 Ingress Device discovery during adoption

I’m running a Debian VM and have the latest version of Unifi OS (with the latest version of the Network application) installed and running on it. I verified everything was working before I even installed the ufw firewall package.

I set up my UFW firewall rules according to the guide at the linked page. However, I think it must be incomplete.

I have just a ton of this in my block logs:

[Sat Sep 12 22:40:40 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=65437 DF PROTO=UDP SPT=10001 DPT=59111 LEN=179 

[Sat Sep 12 22:40:50 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=4206 DF PROTO=UDP SPT=10001 DPT=51451 LEN=179 

[Sat Sep 12 22:41:01 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=6888 DF PROTO=UDP SPT=10001 DPT=46857 LEN=179 

[Sat Sep 12 22:41:11 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=13691 DF PROTO=UDP SPT=10001 DPT=59107 LEN=179 
[Sat Sep 12 22:41:22 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=16639 DF PROTO=UDP SPT=10001 DPT=55631 LEN=179 

[Sat Sep 12 22:41:32 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=26985 DF PROTO=UDP SPT=10001 DPT=57192 LEN=179 

[Sat Sep 12 22:41:43 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.16 DST=10.10.10.20 LEN=199 TOS=0x00 PREC=0x00 TTL=64 ID=37468 DF PROTO=UDP SPT=10001 DPT=34576 LEN=179

I’m not great at reading firewall logs, but what I’m seeing there is that my AP is sending UDP packets from port 10001 on the AP to random incoming ports on the Unifi OS server. I’ve also seen, to a much lesser degree, similar traffic attempting to come from the PC accessing the web GUI.

In any case, I don’t have a firewall rule for this. The only reference to Port 10001 is the ingress rule into Unifi OS quoted above. That’s not what this is.

  1. Is this normal traffic?

  2. If so, what is it trying to do? The AP is already adopted and working, so what is it trying to tell the Unifi OS server? The Unifi OS Network app knows the AP is there, so it’s not the primary heartbeat signal, I don’t think.

  3. Assuming this is normal and we want to allow it, what do we need to add?

    1. As a kludge: I’m thinking: “allow incoming UDP traffic originating on port 10001 from any source on this subnet.” That’s not ideal, and far more permissive than I’d like.

    2. Preferred: “allow incoming UDP traffic coming in on $PortRange” and maybe optionally originating on the subnet from source port 10001.

    3. The Question: What is $PortRange in this case?

I’d appreciate any help. :slight_smile:

Aside from actually solving this problem: The referenced documentation doesn’t mention these ports at all under the section on the Network app, but also doesn’t include a section specific to UnifiOS as a whole.

What’s the best way to file a support request/bug request on the documentation with Ubiquiti?

2

WhatI think is Happening

The UniFi Network Application runs a L2 discovery broadcast worker that periodically scans the local network on UDP 10001 to discover unadopted or existing UniFi devices.

When your UniFi AP (10.10.10.16) responds to the Controller’s discovery broadcast:

  1. The Controller (10.10.10.20) opens an ephemeral client UDP socket (e.g., ports 34576, 46857, 59111).

  2. The AP sends its discovery reply from its static source port UDP 10001 back to the Controller’s ephemeral destination port.

  3. Because UDP is stateless and UFW is dropping the response before conntrack binds the state (or because UFW rules were only defined strictly for static ingress ports), UFW flags these as dropped incoming packets.

The question of whether to allow or block it is do you need L2 discovery or are you going to use the inform URL for adopting devices?

3

Thank you, @LTS_Tom ! :slight_smile:

From some more searching, I’d managed to gather that the traffic was expected, but that’s the best explanation I’ve seen of what’s actually happening.

I wasn’t even aware L2 discovery was a separate thing from Inform-based discovery, so I was quite confused about what was happening. (I also don’t know why devices that have already been discovered and are under the control of the Controller are announcing themselves to be discovered, but I’m sure there’s a good reason.)

I don’t think I need L2 discovery, but on Debian, UFW dumps its log output straight into the dmesg console, which is aggravating when it’s blocking 3 times a second, so I added these rules:

Anywhere                   ALLOW IN    10.10.10.16 10001/udp      # UniFi device discovery - adopted device inbound traffic from UniFi U6 Enterprise AP
Anywhere                   ALLOW IN    10.10.10.0/24 10001/udp    (log) # Unifi device discovery - adopted device inbound traffic from other, unexpected Unifi hardware
  1. The first one is the AP, which is the only hardware I have that I expect to do this, so it’s not logged.
  2. The second one is a logged allow rule so I can see if any other hardware unexpectedly starts doing this.

Doing that cleared out these entries, but it let me notice a new problem. Using the web GUI on my client at 10.10.10.130 generates tons of these:

[Mon Sep 14 16:30:02 2026] [UFW BLOCK] IN=ens18 OUT= MAC=$MAC SRC=10.10.10.130 DST=10.10.10.20 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=65149 PROTO=UDP SPT=61565 DPT=34250 LEN=104

I’ve managed to figure out through some aggressive googling and even caving and asking ChatGPT that this is probably WebRTC traffic from the web GUI at 10.10.10.130 being blocked by Unifi OS at 10.10.10.20.

Again, not something I need, but it’s making a mess of my logs and makes using dmesg for anything but monitoring UFW noise a pain.

I’m left with a conundrum, though. This time, both the source and destination ports are variable. I have no idea how to kludge together a firewall rule that allows these.

Do you have any suggestions? I realize I should probably be happy with “working just fine, but annoying,” but I’d really like to be able to clean up my logs.

4

If you are not going to use the L2 discovery, then block it and ignore it.

1 Like