UniFi Wi-Fi VLAN 10 with a third-party gateway

Research date: 2026-08-08
Scope: evidence-backed design only; no controller, AP, switch, EdgeRouter, or OpenWrt settings were changed by this research.

Answer: who assigns client addresses?

Neither a UniFi Network controller nor a UniFi AP is the DHCP server for a normal third-party-gateway deployment. The controller configures the AP; the AP maps a selected SSID to an 802.1Q VLAN and bridges the client's DHCP broadcast into that VLAN. A UniFi Gateway can provide DHCP, but Ubiquiti's DHCP documentation expressly describes the DHCP server as a service of UniFi Gateways, not APs or the Network Application. UniFi DHCP Server

Accordingly, an existing DHCP server on the native/untagged LAN (here, the EdgeRouter X for 192.168.66.0/24) is expected to answer an SSID that is not actually VLAN-tagged. It must not provide the lease for a genuinely separate dedicated VLAN. That VLAN's gateway would provide its DHCP service.

Required architecture

client → SSID ubnt-upg → U6 Lite
                         │ VLAN 10 (802.1Q tagged)
                         ▼
                every intervening L2 link permits VLAN 10
                         ▼
     gateway VLAN-10 interface: 192.168.10.1/24 + DHCP + routing/OpenClash

The AP's management traffic may remain untagged on LAN66. VLAN 10 is only the client traffic emitted by ubnt-upg; it must be carried, tagged, from the U6 Lite through every intervening switch/link to gfw. Ubiquiti explicitly states that selecting a network for an SSID makes connected clients members of that VLAN and that all ports between AP and gateway must permit its VLAN ID; it recommends AP uplinks be trunked for the relevant VLANs. Creating UniFi WiFi SSIDs

On a managed UniFi switch, this means the AP uplink and every upstream port in the path have native LAN66 (for AP management) plus tagged VLAN 10. Ubiquiti defines that as a trunk, and warns that an AP uplink must not restrict VLANs needed downstream. Switch Port VLAN Assignment

If a non-UniFi switch is in the path, its 802.1Q settings must be configured equivalently (or it must be verified to transparently forward VLAN 10); UniFi does not manage that switch. This is a physical/L2 requirement, so merely creating a controller network cannot make a VLAN reach gfw.

Local feasibility result

The local gfw instance is a VM attached only to untagged LAN 66, and the U6 Lite's physical path is the same ER-X LAN 66 network. No VLAN-capable physical trunk or verified hypervisor/vSwitch VLAN handoff exists between them. The diagram above is therefore a valid design pattern but not a description of the current deployable topology. An eth0.10 interface inside the VM cannot create that missing L2 path.

To make this architecture feasible, add a VLAN-capable switch/trunk from AP to gateway, or configure an end-to-end tagged VLAN handoff through the hypervisor and its physical uplink. Until then, leave the ER-X LAN 66 DHCP design in place and do not expect gfw to serve an SSID-only subnet.

Correct controller model (after the L2 prerequisite exists)

Use one UniFi virtual network for VLAN 10 whose Router is Third-party Gateway and whose VLAN ID is 10; assign that network to Wi-Fi ubnt-upg. Configure the subnet, VLAN and DHCP on the VLAN gateway first. This follows Ubiquiti's documented third-party-gateway workflow: create the VLAN on the gateway, then add a UniFi virtual network with Router = Third-party Gateway and the matching VLAN ID. Creating Virtual Networks (VLANs)

Do not enable a second DHCP service in UniFi for this VLAN. The controller entry is the AP/switch VLAN definition; the gateway on VLAN 10 remains the sole DHCP server and default gateway. The EdgeRouter X's LAN66 DHCP service can remain unchanged because it is for untagged LAN66, not VLAN 10.

Safe verification sequence

Read-only confirm on gfw that its VLAN-10 interface has 192.168.10.1/24, DHCP is enabled for 192.168.10.0/24, and no other DHCP daemon serves that VLAN.
In the controller, verify ubnt-upg selects the Third-party Gateway VLAN 10 network, not Default/LAN66 and not an unassigned VLAN-only placeholder.
Trace the U6 Lite-to-gfw L2 path and permit tagged VLAN 10 on every link while retaining LAN66 as the AP's native/management network.
Reconnect a test client (forget/rejoin or renew lease). The expected lease is 192.168.10.x, gateway/DNS 192.168.10.1 (or the DNS option configured by gfw), never 192.168.66.x.
Confirm a lease appears on gfw and that the VLAN-10 interface's RX/TX counters advance. Ubiquiti's VLAN troubleshooting guide identifies upstream ports not allowing the VLAN as the common cause when Wi-Fi clients cannot receive a correct IP address. Virtual Network (VLAN) Troubleshooting

What the observed `192.168.66.91` proves

It is evidence that the client's DHCP discover reached the LAN66 broadcast domain and was answered by the EdgeRouter X. It does not show a DHCP failure on gfw; it shows that the client was bridged untagged (or VLAN 10 was not carried end-to-end) at that attempt. The corrective work is therefore to make the SSID-to-VLAN association and L2 trunk path real, then test the lease—not to make the AP/controller compete with the LAN DHCP server.

5.7 KiB Raw Blame History