VLANs at home: separating IoT and guests

Your smart plug has no business looking at your NAS, and your guest's phone has even less. A few VLANs and some firewall rules put a door between them.

The short answer

A VLAN splits one physical home network into several logical ones, so IoT gadgets, guests and your own devices live in separate networks on the same cables. For that you need three things: a router or firewall that can route and filter between VLANs, a managed switch that speaks IEEE 802.1Q, and access points that map each Wi-Fi network (SSID) to a VLAN. One point decides whether it works: a VLAN without firewall rules is not protection. The VLAN only separates the networks. The rules between them decide who may talk to whom. Our assessment: three VLANs (trusted, IoT, guest) are enough for most homes.

How it works

1. What a VLAN is. IEEE 802.1Q describes how bridges and VLAN bridges carry several virtual LANs over one network [1]. In practice, a switch inserts a 4-byte tag into the Ethernet frame, between the source address and the type field [2]. The tag holds a 16-bit identifier with the value 0x8100, 3 priority bits, 1 further bit and a 12-bit VLAN ID [2]. The IDs 0 and 4095 are reserved, so you can use 1 to 4094 [3]. Some switches offer fewer: NETGEAR documents 1 to 4093 for one Easy Smart family [6]. A device that does not understand VLAN tags discards tagged frames [3]. Ordinary end devices such as PCs and smart plugs send and receive untagged frames, and the switch port decides which VLAN they belong to [4].
2. Tagged, untagged, PVID. On a switch you tell every port how it treats each VLAN. A port that connects to a client device is an access port: it sends frames untagged and assigns the VLAN to everything coming in. A port that carries several VLANs, for example to the router or an access point, is a trunk port, and its frames are tagged [5]. OpenWrt describes the same idea with its own words: "untagged" frames leave without a tag, "tagged" frames leave with it, and the PVID (port VLAN ID) is the VLAN assigned to untagged frames that arrive [8]. TP-Link describes the PVID the same way, with a default of 1 [7]. The words differ by vendor (access, trunk, general, tagged, untagged), and the IEEE working group notes that "trunk" is not a term of the standard itself [4]. On NETGEAR's fully managed switches you also remove each access port from VLAN 1, because every port starts as a member of VLAN 1 [5][6].
3. Why a VLAN alone protects nothing. Two devices in different VLANs cannot talk to each other directly. Their frames meet only at a layer-3 device, usually your router or firewall. Whether they may talk is decided there. On OPNsense, rules are checked on the interface where the traffic enters, the first matching rule wins, and the default is to block when nothing matches [9]. So a new VLAN is closed until you add a pass rule. The usual pass rule, "allow to any destination", also matches your other VLANs, and everything after it is never reached [9]. Our rule of thumb: block the other internal networks first, then allow the internet.
4. Wi-Fi: one SSID per VLAN. An access point maps each SSID to a VLAN and sends that traffic tagged to the switch. The switch port to the access point must therefore be a trunk that carries the same VLANs [19]. OpenWrt lets you choose the network that a wireless interface attaches to, and the interface then belongs to the right VLAN [8]. Do not create too many SSIDs. Cisco Meraki recommends no more than 3 SSIDs per access point [18], and Juniper Mist suggests 2 or 3 because each SSID adds beacon frames, sent every 102.4 ms at the minimum basic rate, which cost airtime [19]. Trusted, IoT and guest already use three. On the guest SSID, switch on client isolation: peer-to-peer isolation stops devices on the same WLAN from talking to each other [19].
5. Discovery does not cross VLANs. Multicast DNS (mDNS), which phones use to find printers and cast targets, uses the address 224.0.0.251 and does not leave its subnet [11]. If your phone sits in the trusted VLAN and your speaker in the IoT VLAN, the phone will not see it. OPNsense offers an mDNS repeater for 2 to 5 interfaces that re-broadcasts these announcements [10][11]. Use it only between the VLANs that need it, and never for guests. Discovery is not the connection: the stream itself is a normal routed connection, and your firewall rules must allow it. That part is our reasoning, not a quote from the documentation.

What your gear must do

• Router or firewall: one interface per VLAN, a DHCP range per VLAN, and firewall rules per interface. OpenWrt and OPNsense are two documented examples [8][9]. A layer-3 switch can route between VLANs. Check in its manual whether it can also filter, because routing alone gives you no protection.
• Switch: it must support 802.1Q and let you set tagged, untagged and PVID per port [5][6][7]. An unmanaged switch has no VLAN settings, so everything on it lands in whatever VLAN its uplink carries untagged. Read the manual before you switch on the VLAN mode: on NETGEAR's Easy Smart family, enabling Advanced 802.1Q VLAN warns that the current VLAN settings will be lost [6].
• Access point: several SSIDs, each mapped to a VLAN, and a trunk uplink [19].
• Everything in between: powerline adapters, media converters and old switches that do not know VLANs can drop tagged frames. That is why AVM wraps the guest network of its mesh in L2TP tunnels on the LAN instead of tagging it [3][16].
• Clients: nothing to configure. They stay VLAN-unaware [4].

The FRITZ!Box: what the documentation says

The FRITZ!Box is the most common home router in Germany, so this is the question we get most often. As of 25 Oct 2026, we found this:

• AVM documents a VLAN setting for the internet connection: "Use VLAN for internet access" with a VLAN ID, for providers that prescribe one [14][15]. That is about the line to your provider, not about splitting your home network.
• AVM describes two segments in the home: the home network and the guest access. A device connected through guest access cannot reach devices in the home network [13].
• We found no AVM page that describes VLAN tags on LAN ports or SSIDs. A third-party guide from 19 Jul 2026 says the same: only home and guest networks, no tagging [17]. Check the manual and the FRITZ!OS version of your model before you rely on this.
• According to heise, the guest network travels on the LAN between mesh devices in L2TP tunnels, unencrypted, so someone with access to the cable could capture it [16].

That leaves three options. First, use the guest network for guests, and for IoT devices as a coarse first step. All guest devices then share one segment. Second, put a router or firewall that supports VLANs behind the FRITZ!Box and let the FRITZ!Box act as the internet gateway. Port forwards then have to exist on both devices. Third, replace the router. We do not recommend a device here, because the right choice depends on your budget and what you already own.

A three-VLAN plan

This is an example, not a report on our systems. About our own network, only this is documented for this article: the router and firewall sit behind a FRITZ!Box that provides the internet connection (inventory of 14 Oct 2026). The inventory marks VLAN and DHCP as open, so we make no statement about VLANs or rules in use.

Give each VLAN its own subnet and keep the ranges free of overlap with VPN ranges. Do not use VLAN 1 for anything you care about, because every port starts there [6][7]. The management VLAN is optional, but it keeps the admin pages of your gear away from IoT devices and guests.

The firewall rules

The rules are the protection. This set is our suggestion, written in the OPNsense style: rules are checked top to bottom on the interface where the traffic enters [9]. Create an alias that holds the private ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16, here called PRIVATE_NETS. If you want the same rules for IoT and guests, OPNsense can group interfaces so they share one ruleset [12]. Separate rules are easier to read for a start, so the table lists them apart.

Three details matter. First, rule 1 must sit above rule 2, because the DNS server lives inside the private ranges. Second, answers to connections that you opened from the trusted VLAN get through automatically, because the firewall tracks the connection state, and OPNsense expects the return traffic to be allowed by state [9]. IoT devices therefore cannot start connections into the trusted VLAN, but your phone can still control them. If an IoT device must report to one server, such as a home automation hub, add a narrow pass rule above the block, with that one host and port. Third, rules apply per IP version [9]. If your network uses IPv6, write the equivalent rules for it, or switch IPv6 off on the IoT and guest VLANs until you have. If you run a DNS filter, point the IoT DHCP settings at it and allow only port 53 to it. Our articles on zero trust, DNS and Pi-hole or AdGuard Home are listed under Related pages.

Rolling it out without locking yourself out

1. Write the plan on paper: VLAN IDs, subnets, which switch port carries what, and where you plug in your laptop for management.
2. Keep one port as a fallback. Choose a port that stays untagged in your current network, and connect a laptop to it by cable before you change anything.
3. Create the VLAN interfaces, the DHCP ranges and the firewall rules on the router first. Nothing changes for your devices yet.
4. Create the VLANs on the switch, make the port to the router a trunk with all VLANs tagged, and leave the current untagged network as it is [5]. Save the switch configuration, because many switches keep changes only in memory until you save [7].
5. Move one test port into the IoT VLAN as an untagged access port, set its PVID and plug a laptop in [5]. Test with the checks below before you move anything else.
6. Move the access point to a trunk port and add the IoT and guest SSIDs, one at a time [19].
7. Move the real IoT devices, then the guest SSID. Keep the factory-reset instructions of your router and switch at hand.

Testing it

Run these from a laptop on the IoT or guest VLAN. The placeholders stand for your own addresses. A ping alone proves little, because many devices ignore it, so test real service ports.

ip route show default           # via 192.168.30.1: DHCP works
nslookup example.org            # name resolution: works
curl -I https://example.org     # internet: works
nc -vz -w 3 TRUSTED_NAS_IP 445  # trusted NAS file sharing: must fail
nc -vz -w 3 ROUTER_IP 443       # router admin page: must fail

A ping to the gateway 192.168.30.1 gets no answer under these rules, because rule 2 also covers the router's own addresses. From a device in the trusted VLAN, a connection to an IoT device on its web port should work. Look at the firewall log afterwards: the blocked attempts should show up there.

Checklist

• Check that your router, switch and access point support 802.1Q and several SSIDs before you buy anything or start.
• Write down VLAN IDs, subnets and port roles before you touch a setting.
• Keep a cable-connected laptop on a fallback port while you change the switch.
• Add the block rules for private ranges above the "allow internet" rule on the IoT and guest interfaces.
• Allow DNS to your resolver before the block rule, and nothing else you cannot name.
• Mirror every IPv4 rule for IPv6, or turn IPv6 off on those VLANs.
• Limit yourself to three SSIDs per access point and switch on client isolation for guests.
• Repeat mDNS only between the VLANs that need it, and only after you have tried without.
• Test from the IoT and guest VLAN with service ports, and read the firewall log.
• Save the switch and router configuration, and store a copy outside the device.