Networking Basics for Self-Hosters: VLANs, Subnets, and DNS Explained

Networking Basics for Self-Hosters: VLANs, Subnets, and DNS Explained

CompactHost ·

We earn commissions when you shop through the links on this page, at no additional cost to you. Learn more.

When I started self-hosting, I plugged everything into the same switch, used whatever IP my router handed out, and called it a day. It worked — until my IoT thermostat ended up on the same flat network as my Vaultwarden instance and Nextcloud server. That's when I realized that networking fundamentals aren't just "enterprise stuff." They're the foundation of a safe, maintainable homelab. If you've been putting off learning VLANs, subnets, and DNS because they sound intimidating, this guide is for you. I'll keep it practical, with real commands and real configs.

Why Network Segmentation Actually Matters at Home

A flat network — where every device shares the same subnet and can talk to every other device — is a security liability. If a cheap smart plug gets compromised, it can scan and reach your NAS, your password manager, your everything. Segmentation limits the blast radius. Beyond security, it also helps with organization: I can tell at a glance that a device with an address in 192.168.30.x is on my IoT VLAN, while 192.168.10.x is my trusted server VLAN.

This isn't hypothetical hardening. It's the kind of setup that makes running Jellyfin, Immich, AdGuard Home, and twenty Docker containers feel manageable rather than chaotic.

Subnets: Carving Up Your Address Space

A subnet is simply a logical slice of IP address space. Your router hands out addresses within a range, and the subnet mask defines the size of that range. The most common home subnet is 192.168.1.0/24 — the /24 means the first 24 bits are the network portion, leaving 8 bits (256 addresses) for hosts.

For a homelab, I recommend planning your subnets before you need them. Here's the layout I actually use:

You don't need all of these on day one. Start with two: a server subnet and an IoT subnet. That single separation gives you most of the security benefit.

VLANs: Making the Segmentation Physical (Well, Logical)

A VLAN (Virtual LAN) is how you enforce subnet separation at the switch level. Without VLANs, two devices plugged into the same physical switch are always on the same network regardless of their IP addresses. With VLANs, the switch tags traffic so devices in VLAN 10 can't talk to devices in VLAN 30 unless traffic passes through your router or firewall and you explicitly allow it.

To use VLANs you need a managed switch. I use a TP-Link TL-SG108E (about $30), which handles 802.1Q VLAN tagging fine for a homelab. On the router side, I run OPNsense on a small PC, which makes VLAN configuration straightforward.

Here's how to create VLAN interfaces on a Linux machine acting as a router (or on a Proxmox host where you want per-VLAN bridges):

# Install VLAN tools if needed
sudo apt install vlan

# Load the 8021q kernel module
sudo modprobe 8021q
echo "8021q" | sudo tee -a /etc/modules

# Create a VLAN interface for VLAN 10 on physical interface enp3s0
sudo ip link add link enp3s0 name enp3s0.10 type vlan id 10
sudo ip addr add 192.168.10.1/24 dev enp3s0.10
sudo ip link set enp3s0.10 up

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

# Verify
ip -d link show enp3s0.10
ip addr show enp3s0.10

To make these persistent across reboots on Ubuntu/Debian, you'd put the equivalent config in /etc/netplan/ or use a systemd-networkd .network file. If you're using OPNsense or pfSense, the VLAN setup is all done through the web UI under Interfaces → Other Types → VLAN — I won't pretend the CLI approach above is how most people do it in practice.

Watch out: When you move your server NIC onto a tagged VLAN trunk, your SSH session will drop the moment you apply the change if you haven't pre-staged the new interface config. Always have a console (physical or IPMI) available before reconfiguring your network topology.

Inter-VLAN Routing and Firewall Rules

Segmentation is useless if everything can route freely between VLANs anyway. Your router or firewall needs explicit rules. My general philosophy: deny all inter-VLAN traffic by default, then open specific ports where needed. For example, I allow my server VLAN to be reached on port 443 from my workstation VLAN, but IoT devices can only reach the internet — never my server subnet.

On a Linux box using iptables or nftables, here's a minimal example that blocks IoT from reaching servers while allowing established connections:

# Using nftables — save to /etc/nftables.conf

table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    # Allow established/related traffic through
    ct state established,related accept

    # Allow servers VLAN (vlan10) to reach the internet
    iifname "enp3s0.10" oifname "eth0" accept

    # Allow workstations VLAN (vlan20) to reach servers VLAN on HTTPS only
    iifname "enp3s0.20" oifname "enp3s0.10" tcp dport 443 accept

    # Allow IoT VLAN (vlan30) to reach internet only — block everything else
    iifname "enp3s0.30" oifname "eth0" accept
    iifname "enp3s0.30" oifname "enp3s0.10" drop
    iifname "enp3s0.30" oifname "enp3s0.20" drop

    # Log dropped forward packets (optional, useful for debugging)
    log prefix "nft-drop-forward: " drop
  }
}

Apply it with sudo nft -f /etc/nftables.conf and enable the service with sudo systemctl enable nftables. This is a starting point — you'll almost certainly need to add more rules as you add services. The log line is your friend during initial setup.

DNS: The Part Everyone Forgets

Once you have VLANs and subnets sorted, DNS becomes your next headache. The goal for a homelab is local DNS resolution: you want nextcloud.home.arpa to resolve to your server's LAN IP, not go out to the internet. This keeps things fast and means your services work even if your WAN is down.

I run AdGuard Home on my server VLAN as the primary DNS resolver for the whole network. The router hands out AdGuard's VLAN IP as the DNS server via DHCP for every VLAN. AdGuard Home handles ad/tracker blocking and forwards upstream queries to Cloudflare or your resolver of choice. For local names, I use AdGuard's "DNS rewrites" feature:

I prefer .home.arpa over made-up TLDs like .home or .lan because .home.arpa is the IETF-reserved domain for exactly this purpose (RFC 8375). It won't conflict with public TLDs that might emerge in the future.

Tip: Set a secondary DNS server on each VLAN's DHCP scope pointing to a public resolver like 1.1.1.1. That way, if AdGuard Home goes down for an update or a restart, devices fall back to external DNS rather than losing all internet access. Your local names won't resolve, but browsing will still work — much better than a total outage.

If you want a fully recursive resolver with no upstream dependency, you can run Unbound behind AdGuard Home. Unbound resolves from the root nameservers directly. It adds a small latency hit on first queries but means no DNS data leaves your network. I covered the specifics in the Pi-hole and Unbound guide if you want to go that route.

DHCP Reservations vs. Static IPs for Servers

For servers and self-hosted services, I always assign static IPs — either configured on the interface directly or via DHCP reservations (MAC address pinned to an IP in your router). I prefer DHCP reservations because the IP is managed in one place (the router/AdGuard), and the server itself doesn't need to know its own address. The only time I set a static IP on the interface itself is for the DNS/DHCP server — you don't want the server that hands out DNS to depend on DNS to get its own address.

Putting It Together: A Practical Starting Point

If you're starting from scratch and feeling overwhelmed, here's the order I'd recommend:

  1. Buy a managed switch if you don't have one. TP-Link TL-SG108E or TL-SG116E are both solid and cheap.
  2. Set up OPNsense or pfSense on any x86 box with two NICs (or a PCIe NIC card).
  3. Create two VLANs: VLAN 10 for servers, VLAN 30 for IoT.
  4. Deploy AdGuard Home in Docker on your server VLAN and point DHCP DNS entries to it.
  5. Add firewall rules blocking IoT→Server traffic.

This whole setup takes an afternoon the first time. The second time — on your next homelab rebuild — it'll take an hour. And every service you deploy from that point on slots neatly into a segment that makes sense.

If you're running services on a VPS rather than (or in addition to) hardware at home, DigitalOcean's networking primitives — VPCs, floating IPs, and private networking between Droplets — map almost directly to this mental model. Start spending more time on your projects and less time managing your infrastructure. Create your DigitalOcean account today.

Next Steps

Once your VLANs and DNS are in place, the natural next step is securing remote access. I'd recommend either setting up a WireGuard VPN so you can reach your server VLAN from outside, or using Cloudflare Tunnel to expose specific services publicly without opening firewall ports. Both approaches respect your VLAN boundaries and integrate cleanly with the DNS setup described here. Check out the WireGuard VPN tutorial or the Cloudflare Tunnel guide for walkthroughs on both.

Discussion