Once your home network grows a little more complex, you soon realize that grouping devices into virtual local area networks (VLANs) makes a lot of sense, both from a security and administrative perspective. You can keep your IoT devices away from your data stores, group PCs with the printers and other network-connected devices they need, and only let those devices talk to each other, or carry IP camera feeds accessible from one central program.

One of the best tools for this is using managed network switches, which allow you to tag specific VLAN traffic to individual ports, add a guest network for Internet access without being able to access local resources, and use other handy VLAN features. But while VLANs are relatively simple to understand, there's always something I've managed to miss on the first try, whether it's a tagged port or some other part of the transport layer that needs another setting to change. This will break the VLAN as surely as if a physical cable was unplugged, and it's always good to know where to start looking if something goes wrong.

5 Forgetting to forward multicast traffic

Many devices need mDNS access for network discovery

I remember when iTunes first came out and would install Bonjour, Apple's network discovery stack, onto my computer. It never worked right for me on Windows, and clogged up my home network, so I used to uninstall it and use other programs to manage my iPod instead. Nowadays, IP multicast is used in everything from Windows to macOS, phones, IoT devices, smart speakers, network appliances, and more. It's become a foundational smart home technology, and nothing works properly without it.

Oh, how things have changed. The problem with things relying on mDNS is that it can't hop between two IP ranges without a bit of help. So, as soon as you set up a VLAN and move any smart devices onto it, mDNS works on that VLAN and the main network, but there's no bridge between the two. You'll want to go into your router, or firewall, or managed switch, and look for mDNS Repeater and toggle that on. It's also a good idea to enable IGMP Snooping, and set up firewall rules so that UDP 5353 is passed between the VLANs and the main network.

4 Having an unmanaged switch in the path

Not every switch will pass VLAN tags through, breaking your hard work

Imagine this. You've set up a secondary VLAN, made sure you've tagged the trunk ports across your network architecture, and feel pretty good about the skills you've chained together. And then you run out of ports to connect a PC and streaming box in one room, so you plug them into an unmanaged switch, and neither device connects to the VLAN you just spent time constructing. You double-check to see if you've tagged the correct upstream ports as trunk (or with the VLAN you want passed through), but you still don't get any connectivity on the PC or streaming box.

The problem here is that the vast majority of unmanaged switches discard 802.1Q headers, which collapses every frame that goes through to the default VLAN 1. That's not how you wanted your network packets to be sent, and there are only two solutions to be had, both requiring physical hardware. You can add a cheap managed switch instead of the unmanaged one, or run a dedicated line from the router or managed switch to that PC. The easier option is clearly the managed switch, and you can even find ones with PoE+ so you don't need to find a power socket nearby.

3 Clients are connecting to APIPA instead of the expected subnet

If you see 169.254.x.x addresses, you know where to look

While adding new client devices to an AP or managed switch that has VLANs tagged on them, a very common occurrence is that the client gets an IP address in the 169.254.x.x range or another Automatic Private IP address. The cause is the same as any other network type; the client's DHCP discover packets never reach the server, so it never gets assigned an IP address and falls back to the default.

This means a few possible things. The VLAN tag (eg, VLAN 10) could be available on the SSID or managed switch, but the port on the switch that goes to the router is missing the VLAN 10 tag, so those frames don't get passed to the router for DHCP. It could also mean that there are no more IPs to hand out on the DHCP range, either from guest devices taking them all (so change the DHCP expiration to something like 15 minutes to resolve it), or because there aren't enough in the set range, and expanding the DHCP range will fix things.

Oh, and one other thing to check. Proxmox or Docker hosts using proxy-ARP can reply to ARP probes saying they manage an IP address assigned to VMs or containers, instead of on the physical interfaces. This can cause issues if the DHCP pool is too small, leading to clients self-assigning the 169.254.x.x range instead of pulling a valid DHCP IP address.

2 Inter-VLAN traffic doesn't flow as expected

This could block all traffic or it could allow it all, and it's not what you want

Depending on your network hardware and the software running on it, any new VLAN gets a default set of firewall rules. For OPNsense, the default is to block all traffic to and from that VLAN, and you need to add explicit firewall rules to allow traffic, mDNS, and any other packets that the VLAN will need. UniFi is the opposite (as is pfSense), where no firewall rules will be applied by default, and you'll have to add the explicit rules for the traffic you need, then set a block all rule to stop that VLAN from accessing your other LAN segments. And as always, check the ports along the physical connections for that VLAN to make sure they're tagged with the correct VLAN(s) or set as trunk ports.

1 VLAN has DHCP but no Internet connectivity

I wish it wasn't DNS, but it's actually DNS (with a simple fix)

Networking needs a few things to work together for proper packet flow, and it's entirely possible to set up a VLAN, tag all ports and SSIDs correctly, have clients connect correctly and get an IP address, and still not get Internet connectivity. This usually means that DNS or NAT is missing, so we go off to the firewall and DNS resolver. We want NAT rules, so traffic can pass through the firewall from the VLAN to the WAN interface, and another rule so that port 53 can pass the firewall, so DNS traffic goes through. You might also need to add the VLAN or the devices on it to the DNS resolver or forwarder's "listen list," so that it doesn't drop any DNS queries from that VLAN.

I'm sure I'll break more things with VLANs in the future

My home network gets more sprawling by the week, as I discover new best practices and other networking features I've never used before. I currently only have one VLAN on my wireless access points, even though they're capable of multiple VLANs, each with its own SSID. I think that's one of my next things to play with, so I can have dedicated 2.4GHz SSIDs for IoT devices, one for guests, maybe a dedicated SSID for 6GHz-capable clients, and other potential configurations. Whatever I decide, I'm sure I'll break things more often than I get them working (to begin with), but that's all part of the fun.