A VLAN must work across the entire path: client connection, access point or switch port, upstream links, gateway, address assignment and access policy. Creating a network in UniFi is only the starting point.
Need help tracing the VLAN path?
Remote support can review port settings, addressing and rules on an existing network. Include the affected client type and its symptom so we can discuss the right scope.
Start with the client’s actual network information
- No usable address: investigate the physical connection, VLAN transport, DHCP availability and address pool. A failed wireless association also needs to be distinguished from a DHCP failure.
- An unexpected subnet: check the selected WiFi/port network, tagging, stale client configuration and unintended DHCP servers.
- The expected subnet, but no internet: review the gateway path, DNS and relevant policy.
- Internet works, but a printer or server does not: check the intended inter-network access, service discovery and the destination device’s own rules.
Use these observations to narrow the investigation. An IP address alone does not prove that every part of the configuration is correct.
Trace every link back to the gateway
Write down the client-facing port or WiFi network, the AP uplink, any intermediate switches and the gateway connection. Confirm the intended VLAN is carried over each required uplink. A newly installed switch or moved AP can expose a missing link in that path.
Check the native/untagged network separately from the VLANs carried as tagged traffic. The correct configuration depends on what the connected device sends and expects. Avoid applying a single port profile to every connection without checking those roles.
Ubiquiti’s VLAN troubleshooting guide shows common transport and network-override mistakes. Match its examples to your actual topology rather than copying an example VLAN number.
Separate client traffic from device management
An AP may broadcast a guest network while being managed through a different network. If you change its management assignment or the native network on its uplink, you can lose access even when the guest VLAN itself is defined correctly.
Before changing an AP, switch or gateway management path, confirm how you will reconnect if it goes offline. Save the current configuration and arrange local assistance where a remote-only recovery would be uncertain.
Verify DHCP, routing and DNS in order
Confirm which device supplies DHCP and routing for this network, especially if a third-party gateway is involved. Check the address range, subnet and default gateway supplied to the client. Avoid overlapping subnets where distinct routed networks are intended.
Then distinguish reaching an IP destination from resolving its name. A DNS failure can look like an internet outage even when basic connectivity works. A blocked ping by itself is not conclusive evidence that every application connection is blocked.
Keep the required isolation intact
Review the particular service, source, destination and relevant rule direction. Guest isolation, firewall policy and destination-device settings can all matter. Establish the access that is actually needed rather than opening unrestricted communication between guests and business systems.
For an installation or redesign, see commercial network services. For a device that becomes unreachable after network changes, see device connectivity and adoption checks.
Send useful details for remote help
Include the gateway/controller model, VLAN ID, affected WiFi or port, a simple connection diagram, the expected subnet and what works versus fails. Keep passwords, keys and private client details out of the initial form.
Send Your VLAN Support Request
We agree scope, fees, availability and any required access before a session. See remote UniFi support for the process.