# 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](https://help.ui.com/hc/en-us/articles/360012097513-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

```text
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](https://help.ui.com/hc/en-us/articles/26136823938583-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](https://help.ui.com/hc/en-us/articles/26136855808919-Switch-Port-VLAN-Assignment-Trunk-Access-Ports)

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)](https://help.ui.com/hc/en-us/articles/9761080275607-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

1. 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.
2. In the controller, verify `ubnt-upg` selects the Third-party Gateway VLAN
   10 network, not `Default`/LAN66 and not an unassigned VLAN-only placeholder.
3. 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.
4. 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`.
5. 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](https://help.ui.com/hc/en-us/articles/9592924981911-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.