Wife On Separate Vlan

Introduction

The phrase “Wife On Separate Vlan” may sound humorous, but it encapsulates a serious networking challenge that many homelab enthusiasts and self‑hosted DevOps practitioners face daily. When a partner’s devices — smart speakers, IoT gadgets, or personal laptops — share the same broadcast domain as critical servers, the attack surface expands dramatically. A compromised smart thermostat can become a pivot point into your entire infrastructure, exposing SSH keys, database credentials, and CI/CD pipelines.

In this guide we will dissect why isolating family devices on a dedicated VLAN is not just a nice‑to‑have but a best‑practice security measure. You will learn how to design, implement, and maintain a segmented network that protects both your production workloads and the everyday devices of your household. The discussion is rooted in real‑world scenarios: a Reddit user reported a third compromise of his wife’s network, prompting the question — should families be placed on separate VLANs?

Key takeaways for the seasoned sysadmin include:

• Understanding VLAN fundamentals and the security boundaries they create. * Mapping out a concrete network topology that accommodates a homelab, a management network, and a “family” VLAN.
• Executing Docker‑based services within isolated networks without sacrificing automation.
• Hardening configurations to prevent lateral movement from compromised IoT endpoints.
• Leveraging open‑source tools (e.g., Open vSwitch, pfSense, WireGuard) to enforce segmentation with minimal overhead.

By the end of this article you will have a repeatable, production‑grade blueprint that you can adapt to any self‑hosted environment, regardless of size. The content is deliberately technical, avoiding marketing fluff, and is structured to support deep, actionable learning for DevOps engineers who manage complex infrastructure while keeping their personal networks secure.

---

Understanding the Topic

What is a VLAN and Why Does It Matter?

A Virtual Local Area Network (VLAN) is a logical layer‑2 broadcast domain that operates atop a physical LAN. VLANs enable administrators to partition a single switched network into multiple isolated segments, each with its own addressing scheme and security policies. The primary security benefit is that traffic cannot freely cross VLAN boundaries without explicit routing and firewall rules.

In a homelab context, typical VLANs might include:

VLAN ID	Purpose	Typical Devices
10	Management (admin workstations, switches)	Laptops, IPMI, Proxmox web UI
20	Servers (CI/CD, databases, services)	Docker hosts, PostgreSQL, GitLab
30	Family / IoT	Smart lights, voice assistants, cameras
40	Guest Wi‑Fi (visitors)	Guest laptops, phones

By placing family devices in VLAN 30, you create a clear security boundary. Even if a smart bulb is compromised, the attacker cannot directly reach your Docker containers or database servers without first breaching the router’s inter‑VLAN routing policies.

Historical Context

VLANs were introduced in IEEE 802.1Q in 1999 to address the scalability limits of traditional flat networks. Early adoption was driven by large enterprises that needed to segment traffic for security and performance. Within the homelab community, VLAN adoption grew alongside the rise of Docker and Kubernetes, which encouraged practitioners to think of networks as code‑defined resources.

Key Features and Capabilities

• Tagging (802.1Q): Each Ethernet frame can carry a VLAN identifier (VID) ranging from 0‑4095. Switches use this tag to forward frames only within the same VLAN.
• Inter‑VLAN Routing: Typically performed by a dedicated firewall or a layer‑3 switch. Access Control Lists (ACLs) define which VLANs may communicate with each other. * QoS and Bandwidth Management: VLANs can be paired with priority markings to prioritize critical traffic (e.g., VoIP).
• Scalability: A single physical switch can support up to 4,095 VLANs, though practical deployments often stay under 100 for manageability.

Pros and Cons

Advantages	Limitations
Isolation reduces lateral movement risk	Requires careful planning of IP subnets
Simplifies broadcast domain control	Additional configuration on switches/routers
Enables granular firewall policies	Misconfiguration can cause network outages
Facilitates network segmentation for compliance (e.g., PCI‑DSS)	May increase hardware costs if VLAN‑aware switches are needed

Use Cases and Scenarios

• Home Labs: Separate VLANs for CI/CD pipelines, monitoring stacks, and personal IoT devices. * Small Office/Home Office (SOHO): Isolate guest Wi‑Fi from corporate devices.
• Security‑Sensitive Environments: Enforce strict ACLs to protect credentials and secrets.
• IoT‑Heavy Households: Contain vulnerable devices that cannot receive regular patches.

Current State and Future Trends

Modern home routers (e.g., Ubiquiti EdgeRouter, OpenWrt‑based devices) now natively support VLAN tagging and inter‑VLAN routing. In the DevOps ecosystem, tools like Cilium and Calico integrate with VLAN‑aware CNI plugins to provide network policies that align with Kubernetes namespaces. Looking ahead, intent‑based networking platforms promise automated VLAN provisioning based on declarative policies, further reducing manual overhead.

Comparison to Alternatives

Alternative	Isolation Level	Complexity	Typical Use
Firewall rules on a flat network	Low	Low	Simple guest isolation
MACsec / IPsec tunnels	Medium	Medium	Remote site connectivity
Physical network segregation	High	High	Data‑center environments
VLANs	High	Medium	Homelab & SOHO

VLANs strike a balance between isolation and manageable complexity, making them the de‑facto choice for most self‑hosted enthusiasts.

---

Prerequisites

Before diving into the implementation, verify that your environment meets the following technical requirements.

System Requirements

Component	Minimum Specification
CPU	4‑core modern x86‑64 (e.g., Intel i5‑12400)
RAM	8 GB (16 GB recommended for multiple Docker containers)
Storage	250 GB SSD (NVMe preferred)
NIC(s)	At least two physical Ethernet adapters (one for management, one for VLAN‑aware traffic)
OS	Ubuntu 22.04 LTS or Debian 12 (64‑bit)

Required Software | Software | Version | Purpose |

|———-|———|———| | Docker Engine | 24.0+ | Container runtime for services | | Docker Compose | 2.20+ | Orchestration of multi‑container stacks | | Open vSwitch | 2.15+ | VLAN tagging and bridging on Linux | | pfSense (optional) | 2.6+ | Dedicated firewall with VLAN support | | WireGuard | 1.0+ | VPN for remote access without exposing services | | Ansible | 2.15+ | Automation of network configuration |

Network and Security Considerations

1. Dedicated Management NIC: Ensure at least one network interface is reserved for out‑of‑band management (e.g., Proxmox web UI). This NIC should not be part of any VLAN that carries family traffic.
2. IP Subnet Planning: Allocate non‑overlapping CIDR blocks for each VLAN. Example: * VLAN 10 (Management) – 192.168.10.0/24
   • VLAN 20 (Servers) – 192.168.20.0/24
   • VLAN 30 (Family) – 192.168.30.0/24
3. ACL Baseline: Draft a set of firewall rules that default‑deny all traffic between VLAN 30 and VLAN 20, only permitting specific outbound connections (e.g., DNS, NTP).
4. User Permissions: Create a non‑root Docker group for regular users who will operate containers. Ensure that only trusted accounts can modify VLAN‑related iptables rules.

Pre‑Installation Checklist

• Verify physical connectivity of all NICs. - [ ] Confirm switch ports are configured for 802.1Q trunking with the intended VLAN IDs.
• Test basic connectivity (ping, traceroute) between VLAN interfaces.
• Install Docker Engine and verify docker version output.
• Set up Open vSwitch service (systemctl enable --now openvswitch-switch).
• Draft initial firewall rule set in pfSense or iptables.

---

Installation & Setup

The following sections walk you through a reproducible installation of a Docker‑based homelab stack that respects VLAN boundaries. All commands are written to be copy‑paste ready, with placeholders for variables that you can substitute based on your environment.

1. Prepare the VLAN‑Aware Bridge

Open vSwitch provides a kernel‑level bridge that can tag and untag traffic. We will create a bridge named br-vlan30 that will host family devices.

# Create the bridge
sudo ovs-vsctl add-br br-vlan30

# Add the physical interface to the bridge (replace eno1 with your NIC)
sudo ovs-vsctl add-port br-vlan30 eno1

# Set the bridge to accept VLAN tagging
sudo ovs-vsctl set Bridge br-vlan30 vlan-mode=trunk

# Create VLAN interface for VLAN 30 (ID 30)
sudo ip link add link eno1 name eno1.30 type vlan id 30
sudo ip addr add 192.168.30.1/24 dev eno1.30sudo ip link set dev eno1.30 up

Explanation:

• add-br creates an OVS bridge.
• add-port attaches the physical NIC, allowing OVS to manage its traffic.
• set Bridge … vlan-mode=trunk enables the bridge to forward frames with any VLAN tag.
• The vlan interface (eno1.30) receives untagged traffic from the bridge and assigns it to VLAN 30, then obtains an IP address for routing.

2. Deploy a DHCP Server for the Family VLAN

We will use dnsmasq to provide DHCP and DNS services to devices on VLAN 30.

# Install dnsmasq
sudo apt-get update && sudo apt-get install -y dnsmasq

# Configure dnsmasq for VLAN 30cat <<EOF | sudo tee /etc/dnsmasq.d/vlan30.conf
interface=eno1.30
dhcp-range=192.168.30.10,192.168.30.100,12h
dhcp-option=option:router,192.168.30.1
dhcp-option=option:dns-server,192.168.30.1
EOF# Restart dnsmasq
sudo systemctl restart dnsmasq

3. Spin Up Docker Services Within the VLAN

We will run a sample stack consisting of Portainer (for container management) and Nextcloud (for personal file sharing). Both containers will be attached to the br-vlan30 network, ensuring they only see traffic from the family VLAN.

# docker-compose.vlan30.yml
version: "3.9"
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: $CONTAINER_NAMES_portainer
    restart: unless-stopped
    ports:
      - "9000:9000"
    networks:
      vlan30_net:
        ipv4_address: 192.168.30.10
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock      - portainer_data:/data

  nextcloud:
    image: nextcloud:latest    container_name: $CONTAINER_NAMES_nextcloud
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      - MYSQL_PASSWORD=secret_password
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud_user
      - MYSQL_HOST=db