Your Smart TV Doesn't Need to See Your NAS: VLANs for Beginners

Count the devices on your home network sometime. When I did, the ones I actually trusted — laptop, phone, Proxmox nodes, NAS — were badly outnumbered by the ones I can’t audit at all: a smart TV with its own ad platform, a robot vacuum that phones home to a cloud I’ve never seen, a handful of no-name smart plugs bought in a moment of weakness, all sitting on the same network as my family photos. My switch guide introduced VLANs in a couple of paragraphs and promised they were worth learning; this is the follow-through — by the end, your questionable gadgets will live behind an invisible wall, and you’ll understand every setting that built it.

What a VLAN actually is

A VLAN — virtual LAN — carves one physical switch into multiple logical networks. Same box, same cables, but traffic on one VLAN cannot reach another. The mechanism comes from the IEEE 802.1Q standard, and the core trick is tiny: the switch slips a 4-byte tag into each Ethernet frame — the envelope your data travels in on the local network — and that tag names the VLAN the frame belongs to, any ID from 1 to 4094. Every frame belongs to exactly one VLAN, and the switch refuses to deliver it to ports that aren’t members of that VLAN.

I find it easier to see than to read:

On the left, every device can talk to every other device — that’s a flat network, and it’s what you get out of the box. On the right, the same switch enforces membership: the camera’s traffic physically cannot leave VLAN 20, because the switch drops any frame that tries to cross.

Devices on different VLANs can still be allowed to talk — but only through a router, and only if a firewall rule says so. That’s the part that turns “separate networks” into “separate networks with a guarded gate,” and we’ll set it up in Task 2.

Why IoT devices deserve their own network

I’m not picking on smart plugs for fun. Consumer IoT devices ship with old kernels, get patched rarely (if ever), and often can’t run any security software at all. When the Mirai botnet conscripted hundreds of thousands of cameras and DVRs into a weapon for some of the largest DDoS attacks ever seen — armies of hijacked devices all flooding one target with traffic until it drowns — it didn’t use some exotic exploit; it logged in with factory-default passwords. NIST considers the problem serious enough that it published SP 1800-15, an entire practice guide on limiting what home and small-business IoT devices are allowed to talk to, precisely because a compromised gadget’s first move is to explore the network it lives on.

Here’s the reasoning that convinced me: I can’t patch my smart TV’s firmware, audit my vacuum’s cloud, or install anything on a bargain-bin smart plug. What I can control is what they can reach. Segmentation doesn’t make the devices trustworthy — it makes their trustworthiness irrelevant. A hacked plug on an IoT VLAN can see other IoT junk and the internet, and nothing else. My NAS, my Proxmox cluster, my laptop — all invisible to it.

Building that wall takes exactly three switch settings — and three bits of vocabulary that stand between most people and ever finishing.

Tagged, untagged, and PVID — the three words that confuse everyone

Every VLAN tutorial throws these terms around, and in my experience they’re the reason people give up. Let’s fix that permanently. The tag itself is just those 4 bytes inside the frame:

Now the three words, in plain English:

• Untagged port (Cisco folks say access port): the port strips the tag before handing frames to the device. Your TV, your camera, your PC — they all connect to untagged ports and live blissfully unaware that VLANs exist. A port should be an untagged member of exactly one VLAN.
• Tagged port (trunk port): the tag stays on. This is for links that carry multiple VLANs to a device smart enough to read tags — almost always the cable between your switch and your router, or between two switches.
• PVID (Port VLAN ID): the answer to “if a frame arrives without a tag, which VLAN does it join?” The switch assigns incoming untagged frames to the VLAN named by the port’s PVID. The rule that prevents most beginner confusion: an untagged port’s PVID must match the VLAN it’s an untagged member of. Untagged member of VLAN 20 → PVID 20. Always in pairs.

That’s genuinely the whole vocabulary. Tag on the wire for links between smart devices, no tag for dumb devices, PVID to classify what comes in bare.

The plan: three networks in one house

Here’s the layout I recommend starting with — it’s the shape mine settled into after a couple of false starts:

Each VLAN gets its own subnet — its own block of IP addresses. The /24 shorthand just means the first three numbers name the network and the last one names the device, so each network has room for a couple hundred devices.

And the firewall policy, in one breath: IoT can reach the internet and nothing else; Trusted can reach everything; the Lab accepts connections from Trusted only.

Notice that every packet crossing between zones climbs up to the router and comes back down. The switch keeps the VLANs apart; the router is the only bridge between them, which is exactly where a firewall belongs.

Task 1: Build the walls on your switch

I’ll use the TP-Link TL-SG108E as the example because it’s the switch I recommended in the switch guide — if you followed that post, it’s likely the one on your shelf. The concepts — and even the menu names — are nearly identical on Netgear, Zyxel, and friends. TP-Link’s own 802.1Q VLAN configuration guide documents the same flow if you want the vendor’s version.

Our port map for an 8-port switch:

Task 2: Give each network a gate — the router side

Here’s the honest part most VLAN tutorials skip: the switch alone only separates. Your IoT devices now sit on VLAN 20 with no DHCP (the service that hands each device its IP address), no gateway, and no internet, because nothing is routing for them yet. Something on the trunk has to own each VLAN’s subnet, hand out addresses, and decide what crosses between zones. A smart switch like the TL-SG108E can’t do that — it’s a Layer 2 device; it moves frames, it doesn’t route between networks.

You have three realistic options:

1. A router running OpenWrt — my pick for most people. Many consumer routers can be reflashed, and OpenWrt’s VLAN support and zone-based firewall are excellent.
2. A dedicated firewall like OPNsense on a small box — overkill for a first VLAN, wonderful once you’re hooked. Its VLAN interface docs walk through the same concepts.
3. Your ISP’s router — and here I have to be straight with you: most ISP boxes can’t tag VLANs at all. If that’s you, check for a “guest network” feature. It’s a canned, single-purpose version of exactly what we’re building — worse, but not nothing.

On OpenWrt, after creating an interface for each VLAN on the trunk, the firewall policy from our diagram translates almost line for line. In /etc/config/firewall:

config zone
  option name 'iot'
  list network 'iot'
  option input 'REJECT'
  option output 'ACCEPT'
  option forward 'REJECT'

config forwarding
  option src 'iot'
  option dest 'wan'

config forwarding
  option src 'lan'
  option dest 'iot'

config rule
  option name 'Allow-DHCP-IoT'
  option src 'iot'
  option dest_port '67-68'
  option proto 'udp'
  option target 'ACCEPT'

config rule
  option name 'Allow-DNS-IoT'
  option src 'iot'
  option dest_port '53'
  option proto 'tcp udp'
  option target 'ACCEPT'

Reading it back: the iot zone rejects inbound connections to the router and refuses to forward anywhere by default. The first forwarding block opens exactly one door (to the internet), and the second lets your trusted network reach into IoT — replies flow back automatically because the firewall tracks established connections.

The two rule blocks matter more than they look: without them your IoT devices can’t get an IP address or resolve names, because the zone’s input REJECT would eat their DHCP and DNS requests. This mirrors OpenWrt’s own guest network recipe, which is this same pattern under a different name.

If you run Pi-hole (mine lives in an LXC container), hand out its address as the IoT VLAN’s DNS server and you get per-network DNS logs as a bonus — it’s genuinely fun to watch what a smart TV tries to phone home to.

The same three-zone thinking protects the lab side too — more on that in a moment — and if you want your containers riding these VLANs, the LXC networking guide shows the VLAN-aware bridge setup that pairs with this switch config.

The casting gotcha (read this before you blame the firewall)

Not long after I segmented my own network, casting to the TV broke, and I want to save you the detour it cost me. Your phone discovers the Chromecast by asking “who’s out there?” via mDNS — multicast DNS, the protocol behind all those .local names. Google’s own troubleshooting docs show Cast devices advertising themselves with exactly this kind of .local service record, and per RFC 6762, .local names are link-local: they only mean anything on the network segment where they originate. mDNS discovery simply does not cross a router, no matter how permissive your firewall rules are.

AirPlay, Sonos, and most “it just appears in the app” devices use the same mechanism (DNS-SD, RFC 6763).

Your options, from easiest to most correct:

• Keep casting targets on the trusted VLAN. If you cast to the living-room TV daily, maybe that TV has earned trusted status while the no-name plugs stay walled off. Segmentation isn’t all-or-nothing.
• Run an mDNS reflector. Avahi’s daemon can repeat mDNS announcements between networks — set enable-reflector=yes in the [reflector] section of avahi-daemon.conf (documented in the avahi-daemon.conf man page) on a box with an interface in both VLANs. Discovery starts working; you still need a firewall rule allowing your phone to open the actual streaming connection into the IoT VLAN.

# /etc/avahi/avahi-daemon.conf
[reflector]
enable-reflector=yes

Either way, once casting works again, don’t declare victory — a wall you haven’t tested is just a drawing of a wall.

Task 3: Prove the walls hold

Never trust a firewall you haven’t watched fail. The test is simple: stand in each network and knock on doors that should be locked.

ping -c 3 10.0.0.10      # NAS in the lab VLAN
ping -c 3 10.0.20.1   # IoT gateway

sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip link set eth0.20 up
sudo dhclient -1 eth0.20            # should get a 10.0.20.x address

ping -I eth0.20 -c 3 8.8.8.8        # internet: should WORK
ping -I eth0.20 -c 3 192.168.1.50   # trusted PC: should TIME OUT
ping -I eth0.20 -c 3 10.0.0.10      # NAS: should TIME OUT

sudo dhclient -r eth0.20            # release the lease...
sudo ip link del eth0.20            # ...and remove the interface

What’s next

Your gadgets are walled off; the natural next step is deciding what the lab accepts — the Proxmox firewall guide picks up exactly there. And if you want to reach any of these networks from outside the house without opening a single port, that’s what Tailscale is for — the subnet router guide shows the setup.

One last nudge before you go: every address, port number, and VLAN ID above was an example. If a value looks specific to one machine, it’s a placeholder to change — not a literal to copy.

Related posts:

• Home Assistant on a NAS: Why Placement Beats Hardware — the hub that talks to those segmented smart devices, and where to run it
• Choosing a Network Switch for Your Homelab — the hardware this post builds on, and where the VLAN story started
• Proxmox LXC Networking: Static IPs, VLANs, and Bridge Configuration — the Proxmox side: VLAN-aware bridges for your containers
• Proxmox Firewall Guide — zone thinking applied to the cluster itself
• Pi-hole on Proxmox — per-VLAN DNS with logs that show what your gadgets whisper
• Home Assistant on Proxmox — the service that talks to the IoT VLAN more than any other
• Tailscale Subnet Router — remote access to every VLAN without port forwarding
• Proxmox Security Hardening — the other layers of defense around your lab
• Green Lights, No Packets: Common Homelab Network Issues — the troubleshooting companion for when a VLAN looks configured and isn’t

Recommended hardware for this setup:

• TP-Link TL-SG108E 8-port smart switch — the budget VLAN workhorse this guide uses as its example
• Netgear GS308E 8-port smart switch — same class, different menus, equally capable
• TP-Link TL-SG105E 5-port smart switch — the smaller sibling if you only need a handful of ports
• GL.iNet Flint 2 OpenWrt router — ships with OpenWrt, so the firewall config above works out of the box

This post contains Amazon affiliate links (tag: buildahomelab-20). I earn a small commission on qualifying purchases at no extra cost to you.