VLAN Network Segmentation for the Maker Shop: Isolating 3D Printers, CNC Controllers, and Cameras

A typical maker shop network ends up with an uncomfortable mix of devices sharing one flat WiFi network: a 3D printer's OctoPrint or Klipper controller with a known history of exposed, unauthenticated web interfaces, an ESP32 sensor node running whatever firmware you flashed it with last year, a Frigate security camera with full view of your driveway, and the laptop you do banking on. On a flat network, any one of those devices being compromised — and cheap IoT and embedded devices are exactly the class of hardware most likely to have an unpatched vulnerability — puts every other device on the network within reach. VLANs (Virtual LANs) fix this by segmenting devices into isolated broadcast domains that can't talk to each other except through rules you explicitly allow, without needing separate physical networks or routers.

Why This Matters More For a Maker Shop Specifically

This isn't generic home-network paranoia — a shop network has a genuinely higher exposure than a typical home network for a few concrete reasons: maker/hobbyist firmware (custom ESP32 builds, older OctoPrint plugins, hobby project code) rarely gets the same security scrutiny as consumer IoT devices; 3D printer and CNC control boards have shipped with real, documented vulnerabilities (exposed OctoPrint APIs being scraped by search engines and used to remotely start prints or read camera feeds is a well-known example); and a shop network often has more individually internet-connected devices than a typical household, each one a separate attack surface.

The Core Idea: Trust Tiers, Not Just Device Types

Rather than a VLAN per device category, think in terms of trust tiers and design segments around what a compromised device in that tier should and shouldn't be able to reach:

VLAN / TierTypical DevicesAccess Rules TrustedPersonal laptop, phone, desktopFull access to everything, including other VLANs, for administration IoT / Shop Devices3D printers, CNC controllers, ESP32 nodes, smart plugsInternet access allowed (for OTA updates, MQTT to a cloud service if used); no access to Trusted VLAN; access to a shared MQTT/Home Assistant server on a defined port only if needed Cameras / SecurityFrigate NVR cameras, PiKVMNo internet access at all unless specifically required — most security cameras have no legitimate reason to reach the internet, and this single rule defeats an entire category of camera botnet malware; local access only to the NVR server GuestVisitor devicesInternet only, no access to any other VLAN

Hardware: What You Actually Need

VLANs require switch and access point hardware that supports 802.1Q tagging — a plain unmanaged switch and consumer WiFi router generally cannot do this. The realistic hardware options:

• A managed switch (Ubiquiti, TP-Link Omada/JetStream, Netgear's managed line, or an inexpensive used enterprise switch) that supports VLAN tagging per port. This is the piece most shops are missing and the one actually worth budgeting for.
• A router/firewall capable of inter-VLAN routing and rules — pfSense or OPNsense running on a small dedicated appliance or repurposed mini PC is the most capable and most commonly used free option in the homelab/maker community; several consumer mesh systems and prosumer routers (Ubiquiti UniFi, some ASUS and Firewalla products) also support VLANs with a friendlier interface but less granular rule control.
• A WiFi access point that supports multiple SSIDs mapped to different VLANs — this is how wireless IoT devices (ESP32 sensor nodes, WiFi-connected printers) land on the correct VLAN without needing a physical Ethernet port.

A Raspberry Pi isn't the core VLAN-capable router in most setups (a dedicated x86 box running pfSense/OPNsense handles routing more comfortably), but a Pi remains genuinely useful in this architecture as the box running Pi-hole, a Home Assistant/MQTT broker, or a Frigate instance that specific VLANs are allowed to reach — see this site's existing Pi-hole, Home Assistant, and Frigate coverage for those pieces, which slot directly into the IoT VLAN's "allowed destinations" list.

Setting Up a Basic Two-VLAN Split

If a full four-tier setup feels like overkill to start, the highest-value single change is separating "everything with a camera or that talks to the internet unsupervised" from "everything you administer from." A minimal starting point:

• Create VLAN 10 (Trusted) and VLAN 20 (IoT/Cameras) on the managed switch, tagging the uplink port to the router with both VLANs and assigning device-facing ports to the appropriate VLAN.
• On the router/firewall, create a firewall rule blocking VLAN 20 → VLAN 10 traffic entirely, and a second rule allowing VLAN 10 → VLAN 20 (so you can still administer devices from your trusted machine).
• Add a second WiFi SSID mapped to VLAN 20 for wireless IoT devices, keeping your phone/laptop on the VLAN 10 SSID.
• Test the isolation actually works: from a device on VLAN 20, attempt to reach a device on VLAN 10 (it should fail); from VLAN 10, confirm you can still reach VLAN 20 devices for administration.

Common Mistakes

MistakeConsequence Forgetting to tag the switch uplink port with all VLANsDevices on a new VLAN can't reach the router at all — the most common "why isn't this working" cause when first setting up VLANs Allowing IoT VLAN full internet access with no outbound filteringA compromised device can still exfiltrate data or join a botnet — segmentation from your trusted devices doesn't prevent that if the goal is C2/botnet traffic rather than lateral movement Putting a device that needs frequent access to Trusted-VLAN services (e.g. a printer that needs a SMB file share) on the isolated IoT VLAN with no exceptionsBreaks legitimate functionality, leading to "just disable the rule" fatigue — instead add a narrow, specific allow rule for the exact port/service needed No monitoring of what's actually crossing VLAN boundariesFirewall rules with no logging mean a misconfiguration or an active intrusion attempt goes unnoticed — enable logging on deny rules at minimum

None of this needs to happen in one weekend — even the minimal two-VLAN split above meaningfully reduces what a compromised 3D printer controller or a botnet-recruited camera can actually reach. Once the switch and router support VLANs at all, expanding from a basic Trusted/IoT split to a fuller tiered setup is mostly firewall rule work rather than new hardware.