When I’m on my network, it works between devices….

When I’m on cellular, or on another WiFi AP that’s not UniFi,

The VPN won’t ssh to my devices

When I turn on teleport, it works,

But that uses more battery on my cellphone.

So,

How can I allow NetBird VPN to work again?

Setup: UniFi Network 11.0.99, USW Pro Max 24 PoE (firmware 7.5.15), a TCL Google TV on one port, single cable, nothing behind it. Every evening I get "USW Port 10 is experiencing frequent STP role state changes."

What the switch counts on that port, with the TV in standby:

• 6,724 link-downs in 48 hours, about 160 an hour since, against 0 to 6 on each of the other 25 ports.

• A 7-minute capture at 1 Hz of the port's state: 10 Mb/s half duplex 61 % of the time, 100 Mb/s full 25 %, down 15 %. No receive errors. The drops come roughly every 20 seconds, in bursts of 1 to 4 within one second.

• Each bounce counts as STP role changes, hence the alert.

It goes with standby: Home Assistant's connection to the TV changes state 83 to 110 times an hour in standby, against 0 or 1 in 80 to 160 minutes while the TV is on, over three evenings. My guess is the TV's low-power Wake-on-LAN mode renegotiating the link, but I haven't measured the port with the TV on yet. An Apple TV on a USW-Flex showed the same rhythm (down 2.5 to 4 s every 17 to 22 s, only in standby): https://discussions.apple.com/thread/255582358. TCL owners see the Home Assistant side here: https://github.com/home-assistant/core/issues/107649

Two questions:

1. Has anyone found a switch-side setting that stops this without losing Wake-on-LAN, such as Energy Efficient Ethernet or an edge-port setting on that port?

2. Can the STP flapping notification be muted for one port only, rather than for the whole site?

The other options I see are Wi-Fi with the port disabled, or turning off the TV's network standby, which costs the network wake I use. Thank you.

First, thank you for your excellent products and the continuous improvements you bring to the UniFi ecosystem. Your work is greatly appreciated!

I would like to suggest adding two important VPN security features to UniFi Network:

1. Configurable VPN Idle Timeout

1.1. Automatically disconnect or deactivate VPN clients after a configurable period of inactivity (e.g., 15, 30, 60 minutes).

1.2. Allow administrators to configure this setting per VPN server or individual client.

1.3. Optionally require reauthentication before restoring access.

2. Maximum VPN Session Duration

2.1. Enforce a maximum connection duration (e.g., 8, 12, or 24 hours), regardless of client activity.

2.2. Allow administrators to define different policies for different VPN users.

Important Technical Consideration – WireGuard

Unlike traditional session-based VPN protocols, WireGuard does not maintain a conventional authenticated user session or provide a native disconnect mechanism.

Therefore, simply monitoring the last handshake would not be sufficient to reliably detect inactivity.

A proper implementation could involve:

1. Monitoring actual VPN traffic activity per peer.

2. Enforcing idle timeouts through server-side firewall rules or temporary peer deactivation.

3. Supporting configurable maximum access durations.

4. Providing a secure, predictable method for restoring access after a timeout, potentially through reauthorization.

The goal is not merely to disconnect a VPN interface but to ensure that inactive or expired VPN clients can no longer access protected internal networks.

Why This Matters

For business environments, particularly those providing VPN access to employees and external contractors, these controls would significantly improve security by limiting unnecessary persistent network access.

Ideally, administrators should also be able to see the reason and timestamp of each automatic VPN access termination in UniFi logs.

Thank you for considering this feature request and for all the hard work your team puts into UniFi!

Best regards,
ALexX

@UI-Team

For those of us operating separate entry and exit gates, having the ability to assign custom names to each gate would make identification much easier, especially when using the Access and Endpoint apps.

This would be a simple but very useful feature that would improve usability and help prevent accidentally opening the wrong gate.

1. When you purchase a 3 pack, are all the units identical or is one specifically the 'master'?

2. Can you interlink the nodes using Ethernet?

3. Can you purchase a standalone UniFi Express 7 and add it to the mesh?

4. What is the maximum number of nodes in a mesh?

5. If you purchase 2 x 3 pack, can you use 4 nodes for one customer and 2 for another?

6. Is the Wi-Fi feature set more or less the same as using a Cloud Gateway Max, U7 Pro APs and a Professional 8 POE Switch?

8. Thanks

The Core Technical Problem (Same-Subnet Uplinks & Inbound Services)
In datacenter and colocation environments, upstream providers deliver two redundant physical cross-connects (Handoff A and Handoff B) that share the same public IP subnet (typically backed by upstream HSRP/VRRP).

Ubiquiti's standard recommendation—terminating both uplinks into WAN1 and WAN2 on the primary gateway—is technically impossible in this topology for two reasons:

1. Subnet Overlap Restriction: UniFi OS does not allow assigning the same IP subnet to two different WAN interfaces on the same gateway.

2. Inbound Port Forwards & Static IPs Break: When hosting inbound services (web servers, RDP, VPNs, mail) via DNAT/port forwarding on a static public IP, failing over to a secondary ISP/subnet breaks all incoming traffic.

Current Behavior
Currently, Shadow Mode VRRP only triggers a failover if the primary gateway loses power, crashes, or reboots. If Handoff A goes down (dead SFP+ transceiver, cut fiber, or upstream switch port failure) while the primary gateway remains powered on:

• The primary gateway keeps the LAN VRRP Virtual IP.

• The shadow gateway (connected to Handoff B) stays in standby.

• All inbound and outbound traffic goes completely offline despite having a live, identical-subnet uplink on the shadow unit.

Industry Standard Comparison
Enterprise firewalls—including FortiGate, OPNsense/pfSense (CARP interface tracking), DrayTek, and Cisco/Juniper (VRRP Object Tracking)—handle this natively. Each router connects to one cross-connect (Router A -> Handoff A, Router B -> Handoff B) using the same WAN IP configuration (with the standby node's WAN interface held down or passive until promotion). When Router A loses WAN link state, it immediately decrements its VRRP priority so Router B takes over both the LAN VIP and the WAN IP.

Proposed Solution
Add WAN Interface Tracking to Settings > System > High Availability (Shadow Mode):

• Trigger Failover on WAN Link Loss / SLA Failure: If the primary gateway's active WAN port loses physical link (carrier down) or fails configured WAN health checks, automatically demote the primary gateway to standby and promote the shadow gateway.

• Clean WAN State Handover: Ensure the passive/shadow gateway brings up its WAN interface (and sends gratuitous ARP for the shared static WAN IP) only upon promotion, while the demoted primary gateway cleanly drops its WAN/LAN active state to avoid IP conflicts.

Supporting single-subnet dual cross-connects via WAN link failover is a baseline requirement for deploying in real-world colocation and hosting environments.

Thank you.

I can't find the solutionand i'm pretty sure the issue is not from the UGC-Fiber

I joined some pictures to the message

Thank you for your help

I user a number to control the order/sequence for the VLANs.

It works good in the past.

Suddenly I found it's not displayed in A-Z order/sequence.

VLAN 2 display at the bottom.

I check the CLI the sequence is correct,

I check the mobile app the sequence is also correct,

I logoff and login with cached cleared,

I add another test VLAN with different number,

Still not working in the webpage.

Any thing affect it displayed correctly?

Thanks.

@UI-Team

@UI-Glenn

Pic1:

Pic2:

Issue 1: U7 LR doesn't apply a manual 5 GHz channel until it reboots

I set the U7 LR's 5 GHz radio to a fixed channel 36 (40 MHz) and clicked Apply. The settings page showed 36, but the device overview kept reporting it live on channel 157, which it had apparently been on for 12 days. Switching to Auto and back to 36 made no difference. Only a reboot of the AP made it actually move to 36. There was no error or warning in the UI. The configured and actual channels just silently disagreed.

Issue 2: U6+ can't mesh or adopt to a parent on channel 157 (UK)

While the U7 LR was really on 157, the U6+ wouldn't complete adoption over mesh. It sat on "Adopting", then "Adoption Failed", even 4 m from the parent with Mesh Connect on, uplink priority set to the U7 LR, and Wireless Meshing enabled site-wide. Setting the U6+ to Auto didn't help. Once the U7 LR rebooted onto 36, the U6+ meshed and adopted straight away. My guess is that the U6+ doesn't use the UK 5.8 GHz channels (149–165) while the WiFi 7 U7 LR does, so the child can't follow the parent there. I couldn't find this documented anywhere.

Questions: @UI-Team

1. Is the channel not applying until a reboot a known bug on 8.0.76?

2. Should the controller stop a mesh parent from choosing a channel its mesh children can't use, or at least warn about it?

Workaround for anyone hitting this: after changing an AP's channel, check the live channel on the device overview and reboot the AP if it hasn't moved. Keep a mesh parent on 36–48 in the UK if it has older children.

I have ~300 sites in UOS. I have 1 or 2 that have terrible internet and my phone is pinging a few times a day. I can't figure out how to exclude these few sites and still have on for other sites. ANy ideas?

Can anyone explain please, its a new visualisation or a bug?

UniFiOS 6.0.17 | Network 11.0.99

For @UI-Team I attach the support file

Attachments:

• support-FBDC-1794660190831.tgz

Environment: UDM Pro, UniFi OS 6.0.17, Network 11.0.99. Settings → Networks → (network) → DHCP → Add Custom DHCP Options, with Type: Hex Array and Code: 162.

What happens

• A 101-byte value is accepted. At 102 bytes, the field rejects it.

• Values that fit are sent byte for byte (checked in Wireshark). macOS 27 uses them: System Settings lists the resolver under "Encrypted DNS Servers", and the system resolver uses DoH to it even though option 6 still points at the gateway. The length limit is the only thing in the way.

Why 101 bytes isn't enough: each DNR entry repeats the resolver's hostname and IP addresses, and you need one entry per protocol. For an 11-character hostname with two IPv4 addresses:

• DoT, port 853: 41 bytes

• DoQ, port 853: 41 bytes

• DoH (h3, h2), port 443, path /dns-query{?dns}: 63 bytes

That's 145 bytes in total. Even with a one-character hostname, the full set needs 115 bytes, so it can never fit. We had to drop DoQ and the port numbers to get down to 92 bytes. With a hostname longer than 15 characters, even DoT + DoH alone won't fit: dns.provider-name.net needs 112 bytes.

Expected: allow up to 255 bytes, the maximum length of a DHCPv4 option (RFC 2132). Ideally also split longer values across several copies of the option, as RFC 3396 allows.

Feature request: forward the ISP's DNR option to LAN clients. Better than a bigger field would be for the gateway to pass on the ISP's encrypted DNS automatically:

• Request option 162 in its own DHCPv4 requests on the WAN (and option 144 via DHCPv6 and router advertisements).

• Include the DNR data it receives in the DHCP replies and router advertisements it sends on the LAN, as an opt-in setting, since clients then send their lookups to the ISP's resolver instead of the gateway.

• Also let admins configure DNR natively in the network settings, without hand-crafted hex.

Forwarding matters because the other discovery method, DDR (RFC 9462), doesn't survive a gateway that acts as the LAN's DNS server. Clients have to verify the resolver's certificate against the IP address they queried, and no publicly trusted certificate can contain the gateway's private LAN address, so verification fails and clients stay on plain DNS. DNR identifies the resolver by name instead, so verification still works with the gateway in between. If UniFi forwarded option 162, an ISP could roll out encrypted DNS to every UniFi customer just by adding the DNR option to its DHCP servers, with no configuration on the customer's side.

@UI-Team

• UniFi Dream Machine SE, UniFi OS 6.0.17 (kernel 4.19.152-ui-alpine), Network 11.0.99, udapi-server 1.0.3

• ndppd reports version 0.2.4, but the build has later 0.2.x options (autowire, deadtime, promiscuous)

• WAN eth8: r8125 driver 9.012.04-NAPI-RSS, connected to a ZTE MC7510 5G outdoor unit. The operator gives one /64 by SLAAC (no prefix delegation), and the /64 changed on cellular reconnects.

• LAN IPv6 "Single Network": the gateway shares the WAN /64 with one LAN (br3). The generated /run/ndppd_br3_eth8.conf has proxy eth8 { router no; autowire yes; keepalive yes; ... rule ::/0 { iface br3; autovia yes } } and the mirror proxy br3 { router yes; ... rule ::/0 { iface eth8; autovia yes } }. net.ipv6.conf.eth8.proxy_ndp is 0.

Addresses are anonymised to 2001:db8::/32. We have not found what triggers each problem from the UniFi side, so this is a report of what we observed and which workarounds helped.

Problem 1: equal routes to the shared /64 on WAN and LAN

On 2026-11-12, after a prefix change, the same /64 was on eth8 (proto ra metric 256) and br3 (proto kernel metric 256), and this kernel used eth8. Traffic to LAN addresses without an ndppd /128 went out of eth8, and those neighbours went FAILED there. Workaround that worked: the /64 via br3 at metric 128, plus /128 routes via eth8 for the modem's own addresses in that prefix.

Problem 2: the old prefix is not deprecated on the LAN

After the prefix change, a Mac still had the old prefix preferred (pltime 86400) and kept using it as source address. We did not capture the gateway's RA, but the old prefix was no longer usable and nothing deprecated it. Sending one RA with the old prefix at preferred lifetime 0 fixed the Mac at once. Request: keep advertising a replaced prefix with preferred lifetime 0 for a while. RFC 8978 describes the host behaviour; RFC 7084 L-13 / RFC 9096 give the same advice for a changed delegated prefix.

Problem 3: some LAN addresses get no inbound IPv6 (eth8 without ALLMULTI)

The modem finds a LAN address it has not seen with a multicast NS to the address's solicited-node group (ff02::1:ffXX:XXXX), and ndppd should answer for the LAN. While ndppd was running, eth8 was found without ALLMULTI (<BROADCAST,MULTICAST,UP,LOWER_UP>, promiscuity 0), and ip maddr show dev eth8 listed only the gateway's own groups. We don't know whether ALLMULTI was never set or was cleared later.

Observed: a Mac's temporary address had 100 % inbound IPv6 loss from 20:30 to 09:05, while the same Mac's stable address worked (it already had an ndppd /128, so the modem could refresh it with unicast NUD). When tcpdump put eth8 into promiscuous mode, the modem's queued echo replies arrived in the same second. Promiscuous mode lets through both all multicast and extra unicast, so that alone doesn't say which frames were missing. The deciding test: ip link set eth8 allmulticast on with promiscuity left at 0. After that, new addresses on an Android phone worked immediately, and an audio streaming app that used to stall on Wi-Fi with IPv6 played normally.

Requests

1. Keep ALLMULTI on the WAN interface while the NDP proxy runs, and set it again after any WAN interface reconfiguration (this build of ndppd also accepts promiscuous yes).

2. Prefer the LAN for the shared /64 (lower metric on br3), keeping the upstream router's own addresses on the WAN.

3. Deprecate a replaced prefix in LAN RAs after a WAN prefix change.

4. Check upstream ndppd fixes against UniFi's build. ndppd 1.0.0-rc1 captures in promiscuous mode and notes that 0.2.x never saw unicast NS from the upstream router, so entries went STALE and FAILED and ndppd "appeared to work only while tcpdump was running". 1.0 has an incompatible configuration and needs testing.

Related: the "Fix IPv6 failover on UniFi 5G Backup" feature request describes the same cellular /64 rotation. FreeBSD PR 295176 is a separate driver bug with a similar symptom: the rge driver never updated its multicast filter (fixed in commit 7aa34e12c9e1), and ifconfig rge0 allmulti was the workaround there too.

Can provide on request: full ip -6 route, ip -6 neigh, ip -6 rule and ip maddr dumps, the ndppd config, and timestamped WAN and LAN captures.

@UI-Team could you have the Network team look at requests 1–4 above?

• Switch: USW-Pro-HD-24

  • Firmware 7.6.11 (since Nov 8). Earlier events were on 7.2.123 and 7.5.15.

• Gateway: UDM Pro, UniFi Network 11.0.99

• Port 23: NAS

  • Synology DS1825+, DSM 7.4.1-90080

  • NIC: Intel X550-T2 (one port in use), 10 Gb/s full duplex

  • Cabling: 3 ft Monoprice Cat6 SlimRun → Mini-Com female-to-female coupler → 0.1 m UniFi patch cable

  • STP edge enabled (since Nov 13, after the last event)

• Port 24: Server

  • Ubuntu 26.04.1 LTS, kernel 7.0.0-42-generic

  • NIC: Intel X550-T2, ixgbe driver, NVM firmware 0x80000760 / 1.1568.0, 10 Gb/s full duplex

  • Cabling: 4 ft Monoprice Cat6 SlimRun, direct (since Nov 8). Before that, the same as port 23.

  • STP edge enabled (since Nov 8)

What happens

Ports 23 and 24 lose link within 20 ms of each other, stay down about 4 seconds, and come back at 10 Gb/s. This has happened six times since January:

Date    Firmware  Port 23 link down  Port 24 link down
Feb 6   7.2.123   09:55:58.910       09:55:58.890
Sep 25  7.5.15    08:44:04.555       08:44:04.575
Oct 8   7.5.15    07:53:12.755       07:53:12.775
Oct 10  7.5.15    09:40:10.720       09:40:10.740
Oct 17  7.5.15    13:38:32.640       13:38:32.660
Nov 13  7.6.11    14:59:42.130       14:59:42.150

Times are US Pacific, from the switch's syslog. Milliseconds come from the kernel uptime counter in each line. The switch's clock is about 1 second ahead of the server's.

Switch log, Nov 13:

kernel: [421923.370000] Port 23 moving from Forwarding to Disabled
kernel: [421923.620000] Port 24 moving from Forwarding to Disabled
kernel: [421923.870000] Port 23 link down
kernel: [421923.890000] Port 24 link down
kernel: [421927.620000] Port 24 moving from Disabled to Forwarding
kernel: [421927.370000] Port 23 moving from Disabled to Blocking
kernel: [421927.900000] Port 24 link up
kernel: [421927.860000] Port 23 link up
kernel: [421930.370000] Port 23 moving from Blocking to Forwarding

Server log, Nov 13 (UTC):

2026-11-13T22:59:41.324Z kernel: ixgbe 0000:02:00.0 enp2s0f0: NIC Link is Down
2026-11-13T22:59:46.112Z kernel: ixgbe 0000:02:00.0 enp2s0f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX

Observations

• Both hosts lose link. The server logs a link-down at each of the six events. The NAS's carrier-change counter (node-exporter, scraped every 30 s) went up at both events after its last restart, on Oct 17 and Nov 13.

• The switch doesn't restart. Its uptime is continuous through every event, and it logs nothing else around them.

• Events by firmware: 7.2.123 (mid-Jan to late Mar), 1. 7.4.0 and 7.4.1 (late Mar to Jul 31), none confirmed. 7.5.9 and 7.5.10 (Jul 31 to Aug 27), none. 7.5.15 (Aug 27 to Nov 8), 4. 7.6.11 (since Nov 8), 1 so far.

• The sequence changed with the firmware. On 7.2.123, port 24 went down first, and the link-down lines came before the ports left Forwarding. On 7.5.15 and 7.6.11, port 23 goes down first, and both ports leave Forwarding 0.3–0.5 s before the link-down lines.

• Neither host logs a cause. The server shows only link down and link up: no driver resets and no CRC or receive errors.

• It continued after re-cabling. Port 24's cabling was replaced on Nov 8, and the Nov 13 event followed.

• Possible earlier events: on Jul 8 and Jul 20 (firmware 7.4.1), the switch logged only port 23 going down, but the server lost link in the same second.

A support file is attached for device and console.

Is anyone else seeing this behavior with their USW-Pro-HD-24 or 10G copper links?

@UI-Team are there any known issues with 10G links on this switch/firmware?

I made these policies (see pic) and wonder if they work or not?

I disabled "auto allow return traffic" and both rules disappear but if I re-enable it, 2 rules come back.

Only one rule shows a hits counter tho.

Is this a bug, or am I missing something?

Network 11.0.99

Gateway Pro 5.1.35

Paid up version of Proofpoint

We're seeing IDS triggering on a significant number of SMB connections from one host in one zone to another in another zone, which in and of itself I'm not fussed about it detecting - thats fine. This is definitely an IDS block not a firewall (I get the CEF info panel in Logs, and its blocking

We used to see, in logs, "Threat detected and blocked" event, with an option to suppress, ignore that Dst / Src IP etc. This would add it to settings -> cybersecure -> threat management. This no longer appears.

In addition, some detections (including the ones I'm interested in) are visible in logs but not flows. It appears flows does not show IDS/IPS - only firewall hits.

Something seems off here - Flows is not showing the threat detections at all. Seems like a new bug. @UI-Team

I have also just tried updating the GW to the slightly newer version (seems to be just the eMudhra certs), same deal.