Limit Unifi Software Controller Plugin to LAN

[OmegaWaffle]

I recently installed OPNsense along with the Unifi Software Controller plugin for my U6 pro, but the web ui is accessible from my WAN ip. I was under the impression the WAN blocks all connections by default, and I see no port forwarding rules. I also see no way to bind the software to a certain interface inside the Web UI. Any advice on how to only allow connections from my lan, and preferably a single IP?

Thank you!

[patient0]

but the web ui is accessible from my WAN ip. I was under the impression the WAN blocks all connections by default

The default is indeed block all on WAN, do you have floating rules that may have an effect on WAN?

How does your network layout look like?

[mimugmail]

There must be an error on your wan rules

[meyergru]

You probably installed the Unifi Controller Plugin with a Unifi account instead of just a local account, which is encouraged by the workflow for the setup.

In that case, you attach the controller to the Unifi cloud, which gives you access. This is not a direct WAN access, but a reverse tunnel, which is just as bad.

You have to realise that any network connection can be reversed, so one a device has an outside connection to some kind of cloud, it could be exploited to break into your network. That is the reason why I put all devices that I do not fully trust into a separate (V)LAN. This includes cloud-based IoT devices, media servers like Plex, printers and even smartphones.

The Unifi controller is a network management tool that has privileges access and thus should never be exposed by connecting it to the cloud, IMHO.
It is trustable only when that cloud connection is capped.

You can remove the cloud connection ("Remote Access" in the image) after the fact by first creating a local user with admin rights and then disabling the Unifi cloud connection. Maybe you first have to enable "Professional Installer", IDK exactly.

You cannot view this attachment.

[OmegaWaffle]

You probably installed the Unifi Controller Plugin with a Unifi account instead of just a local account, which is encouraged by the workflow for the setup.

You are correct, I did set it up with a Unifi Account. I've deleted the plugin and started from scratch with a local account, along with tried to access my ip from a device completely unconnected to my network. It looks like I can no longer access the web UI, but when starting an nmap scan against my IP, I get open ports on 6789, 8080, and 8443. From what I can tell those are all used for Unifi equipment, so is there still accessible services on my network? Or am I misunderstanding the results of the nmap scan?

[Patrick M. Hausen]

If you run the scan from the internal network, you probably have that traffic allowed by rules on LAN. You need to scan from a host outside on the Internet to get a proper picture.

[OPNenthu]

For convenience, I sometimes use the ShieldsUp! tool from GRC to initiate port scans on my public IP: https://www.grc.com/shieldsup

You can use the "User Specified Custom Port Probe" option to scan your ports 6789, 8080, 8443 and any others.

IMHO the self-hosted UniFi controller (especially with a local account) could be tamed even more for home internet users.  It likes to send telemetry and usage data which is fine for organizations, but I don't want it on my private network.  If you feel the same you can optionally add these to your DNS blocklist until such time that Ubiquiti gives us a proper way to disable it.

Code Select Expand

trace.svc.ui.com
crash-report-service.svc.ui.com

And yes, these domains are queried despite that I have the Analytics option unchecked in Settings.  Apparently unchecking that only anonymizes the data, based on some Reddit reports.  That unnecessarily sets up the conditions for a trust issue and I wish they would just fix it.

[meyergru]

IMHO the self-hosted UniFi controller (especially with a local account) could be tamed even more for home internet users.  It likes to send telemetry and usage data which is fine for organizations, but I don't want it on my private network. If you feel the same you can optionally add these to your DNS blocklist until such time that Ubiquiti gives us a proper way to disable it.

In order to really block those sites, you also have to redirect and DNS requests to your Unbound instance.

Up front: It is quite complicated to really block DNS for trace.svc.ui.com and crash-report-service.svc.ui.com.

At least with Unifi OS Server, I saw it uses Cloudflare and Google DNS and not the locally assigned DNS server. Thus, OpnSense is probably not asked for the names mentions. In this case, it might be easier to block access to the Amazon Cloud (ASN 16509) instead - although that may change in the future or may be regionally different and also block updates.

There is (or better, there was) a proper way to disable it...


This is for Unifi OS Server (or UOS):

You cannot view this attachment.

And this for Unifi Network Conroller:

You cannot view this attachment.

To disable even "anonymous" analytics, there "was" a proper way. It was even documented here:

https://help.ui.com/hc/en-us/articles/360042384093-Analytics-Data-Collection-FAQ

But Ubiquiti since removed it.

The instructions said, you need to add this to your /var/lib/unifi/data/system.properties (for Unifi network controller) or /home/uosserver/.local/share/containers/storage/volumes/uosserver_var_lib_unifi/_data/system.properties (for UOS) file:

Code Select Expand

analytics.enabled=false
config.system_cfg.1=system.analytics.anonymous\=disabled

The first line probably corresponds to the UI setting, the second line eliminates analytics completely.

However: The "old" way of disabling anonymous analytics by putting the setting into system.properties has been superseded with Unifi controller 8.x by having to use new config file(s) per site.

For UOS,  these are located under /home/uosserver/.local/share/containers/storage/volumes/uosserver_var_lib_unifi/_data/sites/<site>/config.properties, for Unifi Network Controller, they should be at /var/lib/unifi/data/sites/<site>/config.properties.

Usually, the first site is named "default".

Notice: The line you have to put in there is slightly different (the backslash is missing!):

Code Select Expand

config.system_cfg.1=system.analytics.anonymous=disabled

I put the setting into both system.properties and config.properties for good measure.

You also have to restart your controller or UOS instance and have to force-push a configuration to your APs (e.g. by changing some setting) in order to make it work.

You can then verify by using "grep analytics /tmp/system.cfg" in a ssh shell on your AP. Both system.analytics.status=disabled and system.analytics.anonymous=disabled should show up. I checked that my UOS instance does not use the Amazon Elastic cloud addresses at all. I did not check this specifically on the Unifi Network Controller for OpnSense, as I do not use it.


Most of this info comes from here (read the last posting):

https://community.ui.com/questions/Disabling-trace-svc-ui-com-tracking-yet-again/da39eba4-70fa-4984-9f41-66881534e09f

[OPNenthu]

You seem to be running a special enterprise edition (UniFi OS Server)?  I have no such options and my interface looks different.

I will look for a system.properties file regardless.  Thanks for the tip!

[meyergru]

Yes, I use UOS, but that setting exists in Unifi Network on the same page...
You cannot view this attachment.
The settings file is the same as well. It is even a little more difficult to find in UOS, since that runs within a Podman container, so the path is different, namely: /home/uosserver/.local/share/containers/storage/volumes/uosserver_var_lib_unifi/_data/system.properties

[OPNenthu]

I know... but if you see my earlier post, I have it disabled already.  Regardless, it queries 'trace.svc.ui.com' very frequently as per Unbound logs.

Based on my reading online that setting in the UI does not disable telemetry.  It only controls whether or not the telemetry is anonymized or contains plain IPs & MAC addresses.

[OPNenthu]

Code Select Expand

analytics.enabled=false
config.system_cfg.1=system.analytics.anonymous\=disabled

@meyergru Thanks for bringing these to my attention.  I use the linuxserver.io docker image and in their repo they don't have these keys in the default system.properties file.

Since I mount the /data directory as a volume, I made the edits in my local copy and restarted the container.  I checked in the running container's filesystem and it looks like they got picked up:

Code Select Expand

reporter-uuid=<redacted>
is_setup_completed=true
debug.mgmt=warn
db.mongo.local=false
debug.setting_preference=auto
config.system_cfg.1=system.analytics.anonymous\=disabled
is_default=false
uuid=<redacted>
db.mongo.uri=mongodb\://unifi\:<redacted>@unifi-db\:27017/unifi?tls\=false&authSource\=admin
statdb.mongo.uri=mongodb\://unifi\:<redacted>@unifi-db\:27017/unifi_stat?tls\=false&authSource\=admin
unifi.db.name=unifi
debug.device=warn
analytics.enabled=false
debug.system=warn
debug.sdn=warn

However, I'm still seeing the constant queries in Unbound:

You cannot view this attachment.

I found another project that implemented these same config options, and in that thread they gave some instructions how to check the UniFi devices over SSH.  My switch and AP both only report the 'system.analytics.status=disabled' option after these changes.  The second one is not listed on either device.

Code Select Expand

BusyBox v1.25.1 () built-in shell (ash)


  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2024
 |   |  |   |  \  ||  \   |  |   Ubiquiti Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com

      Welcome to UniFi USW-Pro-Max-16-PoE!

********************************* NOTICE **********************************
* By logging in to, accessing, or using any Ubiquiti product, you are     *
* signifying that you have read our Terms of Service (ToS) and End User   *
* License Agreement (EULA), understand their terms, and agree to be       *
* fully bound to them. The use of SSH (Secure Shell) can potentially      *
* harm Ubiquiti devices and result in lost access to them and their data. *
* By proceeding, you acknowledge that the use of SSH to modify device(s)  *
* outside of their normal operational scope, or in any manner             *
* inconsistent with the ToS or EULA, will permanently and irrevocably     *
* void any applicable warranty.                                           *
***************************************************************************

USWProMax16PoE-US2.7.1.26# grep analytics /tmp/system.cfg
system.analytics.status=disabled
USWProMax16PoE-US2.7.1.26#


Code Select Expand

********************************* NOTICE **********************************
* By logging in to, accessing, or using any Ubiquiti product, you are     *
* signifying that you have read our Terms of Service (ToS) and End User   *
* License Agreement (EULA), understand their terms, and agree to be       *
* fully bound to them. The use of SSH (Secure Shell) can potentially      *
* harm Ubiquiti devices and result in lost access to them and their data. *
* By proceeding, you acknowledge that the use of SSH to modify device(s)  *
* outside of their normal operational scope, or in any manner             *
* inconsistent with the ToS or EULA, will permanently and irrevocably     *
* void any applicable warranty.                                           *
***************************************************************************

  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|   PRODUCT: U7-Lite
 |   |   /    \|  ||  __) |  |   MAC:     <redacted>
 |   |  |   |  \  ||  \   |  |   VERSION: 8.0.49+16814.250620.0938
 |______|___|  /__||__/   |__|
            |_/

Ubiquiti Inc. (c) 2010-2025      https://www.ui.com

admin@U7Lite:~# grep analytics /tmp/system.cfg
system.analytics.status=disabled
admin@U7Lite:~#

In that same thread, the developer makes a mention to also disable "n the DNS blocker". So I don't know what the story is. :-/

I'll do some more research on this but returning the thread back to its owner now (apologies...)

----

UPDATE (because I can't resist):

I consulted with my chronically hallucinogenic and sociopathic liar AI frienemy and it had this to say (abridged for brevity) -

Code Select Expand

## ❌ Why `system.properties` Isn't Enough

The `system.properties` file applies only to the **UniFi Network Application** (the controller), not the firmware running on UniFi devices.

Settings like:

```properties
analytics.enabled=false
config.system_cfg.1=system.analytics.anonymous=disabled
```

...will **only stop controller-side anonymous usage stats** and sometimes crash reports. They do **not disable device telemetry**.

---

## 🚫 What You *Can't* Do (Yet)

* There is **no supported UniFi setting or flag** to completely stop telemetry at the **device level**.
* Even Dream Machines (UDM/UDM-Pro/UDM-SE) **continue phoning home** unless you intercept/block traffic at DNS or firewall level.

---

## ✅ Summary: How to Truly Block UniFi Telemetry

| Method                                   | Effectiveness               | Breaks Anything?        |
| ---------------------------------------- | --------------------------- | ----------------------- |
| `system.properties` settings             | ❌ Partial (controller-only) | ❌ No                    |
| DNS blackhole (`trace.svc.ui.com`, etc.) | ✅ Best method               | ❌ No                    |
| Firewall block outbound to telemetry     | ✅ Effective                 | ❌ No                    |
| Disable internet for controller/device   | ✅ Extreme                   | ⚠️ Yes (cloud, updates) |



On this occasion, I actually hope it's lying to me again.

[meyergru]

It is lying... I updated my post about how to set this correctly.