If you have not yet created your virtual networks, check out Creating Virtual Networks article for in-depth configuration assistance.
The Basics of Network Connectivity
There are two key principles you should be familiar with:
- Messages between clients on different virtual networks must first pass through a gateway.
- Each client must have an IP address. This is usually obtained from its network’s DHCP server.
Cross-network communication requires traffic to pass through the gateway, even if the two devices involved are located in close proximity to each other. Prior to routing the message to the recipient’s virtual network, a gateway will first apply all active Traffic Management and advanced routing rules. Many administrators set up these rules to isolate the traffic of multiple virtual networks to ensure optimal data security.
This traffic flow is illustrated below. Note that if both laptops were connected to the same virtual network, they would be able to communicate with one another without a gateway.
Obtaining an IP Address via DHCP
All UniFi gateways have a full DHCP server integration to streamline client IP assignment without the need for advanced configuration. That said, users who prefer to implement a third-party DHCP server can still do so.
Each client connecting to a network for the first time goes through a four-step process to obtain an IP address. Assuming there are no inhibiting traffic rules or port restrictions, it is as follows:
- Discovery: The client sends an initial broadcast message to all clients on the virtual network to locate the corresponding DHCP server.
- Offer: The solicited DHCP server offers the client an available IP. Sometimes, clients receive offers from multiple servers.
- Request: The client requests one of the offered IPs.
- Acknowledgement: The DHCP server assigns the requested IP and sends a confirmation message to the client.
This process is illustrated below. The scenario is a mobile device connecting to a WiFi SSID.
In this example, the gateway has an integrated DHCP server, which is uniquely advantageous because traffic from all virtual networks can communicate with the gateway.
Some users opt to support their virtual network with a third-party DHCP server independent of their gateway. Since broadcast traffic is not passed across multiple virtual networks, a DHCP Relay may be required if a client needs to obtain an IP from a server on a different virtual network. This is a more complex configuration outside of our support scope, which is why we recommend using a UniFi gateway with an integrated DHCP server.
Virtual Network Isolation
This can be achieved by applying:
- Traffic Rules: Commonly referred to as firewall rules, determine how client traffic is directed when it passes through a UniFi gateway. They can be used to isolate or allow specific network and device traffic.
- Port Restrictions: This is primarily used to limit the amount of broadcast traffic because it normally will be sent to all ports that accept messages from the source’s virtual network. Networks allowed to pass traffic through designated ports are traditionally referred to as Tagged Networks by third-party providers. Omitting a specific network from a tagged network list will prevent its traffic from passing through any ports.
Troubleshooting Network Connectivity
Always exercise caution when applying rules to your virtual networks to avoid inadvertently degrading connectivity. The diagram below shows how connectivity can be disrupted by improper network configuration.
Port Restrictions Preventing Devices from Obtaining an IP from a DHCP Server
A device will not be able to obtain an IP address if any port between it and the DHCP server restricts traffic from the network it’s attempting to connect to.
UniFi devices that fail to obtain an IP cannot be adopted. If this occurs, they will automatically revert to their default address: 192.168.1.20
Third-party clients that fail to obtain an IP will not be able to connect to their intended WiFi SSID. For example, iPhone 1 will not be able to obtain an IP address if VLAN 10 is restricted on (7), (5), (4), (3), or (2).
This client scenario is often caused by an admin applying port restrictions when initially setting up their WiFi SSID, then forgetting to modify those restrictions when creating a new network, like a guest hotspot.
Gateway Rules Limit Internet Access and Cross-Network Communication
Please review your traffic rules to ensure that none are configured to restrict internet traffic or cross-network device communication.
Smart Home and IoT Devices Cannot Be Discovered Due to Multicast Traffic Restrictions
Multicast traffic is similar to broadcast traffic, except that messages are sent to devices in a designated “multicast group” instead of across the entire network. This communication protocol is required by many devices and applications, including Philips Hue, Nest Thermostat, Apple AirPlay, and Chromecast.
If you’re having trouble with multicast applications, such as AirPlay or Chromecast, enable MDNS in your Global Network Settings. This setting should be enabled on both networks in the case of cross-network multicasting (e.g., casting from an iPhone on VLAN10 to a TV on VLAN20).
Devices Cannot Communicate with One Another
This occurs if you have any traffic or firewall rules restricting traffic across multiple networks. We recommend disabling these to ensure your devices can communicate.