Your Home Network Should Be Two: IoT Isolation and VLAN in Practice

Smart bulbs, door locks, cameras, smart fridges, smart switches… these IoT devices are quietly turning your home network into a high-risk zone. In his latest video, YouTube channel Network Chuck demonstrates how to carve out multiple isolated networks with a single device, and the core takeaway is clear: your home needs at least two networks, and VLAN is the key technology that makes this possible on a single router.

Why a Single Network Is Dangerous

The video opens with an easily overlooked fact: as long as one device has a vulnerability, a skilled attacker can use it as a springboard into the entire home network. You can't predict which IoT device has a vulnerability until it's exploited. Worst-case scenarios include malware spreading across the home network, devices being recruited into botnets to attack hospitals, or home camera feeds being live-streamed to the internet.

A piece of advice from IoT security expert Bogdan is repeatedly cited: if you have the network equipment for it, isolate your IoT devices; if not, at least move them to a guest network—that's already much better for core network security. The logic of isolation is this: even if an IoT device gets infected or taken over, it can't reach the rest of your home's devices.

VLAN: Multiple Networks Out of One Device

Most home routers don't support multiple networks—that's the bad news. But the video's author built an open-source firewall, OpenSense, on a mini PC bought in Japan, and the problem was solved. The core technology for achieving multiple networks is VLAN (Virtual LAN).

VLAN is essentially about virtualizing additional networks on a single physical interface. In practice, in OpenSense you go to Interfaces → Devices → VLAN, click the plus sign to create a new one, set the parent interface to the LAN port, specify a VLAN tag (the video uses 13 for the user network), and save. In theory you can create thousands of additional networks with just that one physical device.

The key limitation is that a VLAN must be attached to a physical interface, and that physical port is shared by all VLANs. This also explains why switch configuration is necessary later—traffic for multiple VLANs needs to be carried over a "tagged port" (also called a trunk port).

VLAN (Virtual LAN) is a Layer 2 network segmentation technology defined by the IEEE 802.1Q standard. It inserts a 4-byte tag field into Ethernet frames, of which 12 bits identify the VLAN ID (valid range 1–4094, with 0 and 4095 reserved), so in theory a single physical link can carry up to 4094 logical networks. Tags are only passed between network devices such as switches and routers; frames sent by end devices are usually untagged, and the access switch adds the corresponding VLAN tag based on port configuration. Devices in the same VLAN communicate directly at Layer 2, while traffic between different VLANs must be forwarded by a Layer 3 device (such as a router or firewall), creating a natural isolation boundary. This is also the technical basis for the article's point that "cross-VLAN access must first be routed through the firewall."

The Switch: Not Just Any Switch Will Do

The video specifically distinguishes three types of switches: unmanaged switches are just "power strips for the network," with no brain; regular managed switches offer configuration capabilities like VLANs; and the author's QNAP switch is a "managed light," with a less intuitive configuration approach.

On the switch side, the port connecting to the firewall needs to be set as a tagged port so it can carry traffic for multiple VLANs simultaneously; ports connecting to end devices are set as untagged and assigned to a specific VLAN. The end devices themselves don't need to know VLANs exist at all—the tagging happens entirely on the switch. The author briefly couldn't find the configuration entry in the QNAP interface, and finally discovered that you just click the plus sign and enter the port number, joking that "I'm just dumb."

Tagged ports and untagged ports are core concepts for understanding VLAN switch configuration. Untagged ports (also called access ports) typically connect to end devices; the switch tags frames with the port's VLAN when receiving them and strips the tag when sending, so end devices are completely unaware of VLANs. Tagged ports (also called trunk ports) are used for uplink links between switches and routers, firewalls, or other switches, allowing tagged frames from multiple VLANs to pass simultaneously—like a "highway" carrying multiple logical networks. When creating a VLAN on a firewall device like OpenSense, the physical port corresponding to the parent interface must be configured as tagged on the peer switch; otherwise tagged frames will be dropped or not correctly recognized. Configuration also requires attention to the Native VLAN setting; mismatches between the two ends can cause untagged traffic to be assigned incorrectly.

The Three Pieces That Make the Network Actually Work

Creating a VLAN alone isn't enough. It took the author a full day to figure out that a usable network needs three things:

VLAN interface: Create a new interface for the VLAN in OpenSense's interface assignments and give it an IP address. This is essentially giving the new network a router to talk to. The author chose the private address 172.16.14.3.

DHCP service: Devices need to automatically obtain an IP address when joining the network, which is handled by DHCP. The author set up an address pool from 172.16.14.100 to 172.16.14.200 with a subnet mask of 255.255.255.0, providing 102 assignable addresses—more than enough for a home network. Here he hit a major pitfall—DHCP by default only listens on the LAN interface, and you must manually check the new interface in the General tab of the DHCP settings, otherwise devices will never get an address. The author admits this setting is "hidden too deep" and was only discovered with the help of AI tools.

Firewall rules: OpenSense denies all traffic by default, which is both its strength and its annoyance. The author added a rule allowing the work network to access any destination, and only then did the network actually connect.

DHCP (Dynamic Host Configuration Protocol) is responsible for automatically assigning parameters such as IP address, subnet mask, default gateway, and DNS server when a device joins a network. Its workflow is commonly summarized as the four DORA steps: Discover (the client broadcasts to find a server), Offer (the server offers an available address), Request (the client requests that address), and Acknowledge (the server confirms the lease). DHCP servers are often bound by default to listen only on specific interfaces; when a new VLAN interface is added, that interface must be explicitly enabled in the service configuration, otherwise Discover broadcasts from the new subnet won't be answered and the device will appear to be "connected but unable to get an IP." The size of the address pool is determined by the subnet mask—for example, a /24 subnet provides 254 usable host addresses, and the 100–200 range set in the article carves out a segment for DHCP dynamic allocation, with the remaining addresses reserved for static devices.

Isolation Verified: The IoT Network Is Successfully Blocked

After configuration, the author made a smarter design: create an alias that groups the home's other private networks together, then set a rule for the IoT network—block any traffic coming from the IoT interface that tries to access that alias group.

The test result was decisive: devices in the IoT network cannot ping any device in the main network. Although they are physically connected to the same switch, even the same firewall, cross-VLAN access must first be routed through the firewall, and the rule explicitly denies it. The exact quote from the video: "We successfully deployed a separate network on this device, completely isolated from the other networks, and IoT devices can no longer attack us."

The video also mentions a noteworthy detail: the author connected an AI agent running on a Raspberry Pi (named "pig") to the firewall and switch, laying the groundwork for future automated management. However, the Wi-Fi part is not yet covered and is left for the next episode.

An "alias" in a firewall is a named object in the OpenSense/pfSense ecosystem that groups a set of IP addresses, subnets, or ports under a logical name for use in rules. Its value lies in maintainability: when the home network adds a new private subnet, you only need to update the alias members, and all blocking rules referencing that alias take effect automatically—no need to modify each rule individually. In the article, the home's other private networks are grouped into an alias, and then a rule is set for the IoT interface to "block traffic destined for that alias," effectively building a least-privilege policy of default deny with allow-by-exception. Note that firewall rules are typically matched from top to bottom, and the first match takes effect, so blocking rules should be placed before allow rules, or you can use an interface-level default deny policy combined with explicit allows.

Implications for Ordinary Households

The barrier to this setup is needing a device that can run OpenSense and a switch that supports VLANs—it's not plug-and-play. But the principle it reveals applies to every home: IoT devices should not be on the same network plane as devices carrying work and private data. Without professional equipment, the router's built-in guest network is the lowest-cost isolation method. Another data point cited in the video is equally worth heeding—attackers now increasingly "log in directly" rather than "break in," and the stolen information often comes from infostealer malware on endpoint devices. Cybersecurity is a layered matter, and network isolation is just one layer.