Personal Homelab

Ryan Pek (b. 2001) | 2nd Year Undergraduate SUTD | Canned food enjoyer

Overview

This is my personal homelab — a self-hosted ecosystem of servers and services for development, media, and experimentation.

Blindly charging into 802.1q (VLANs) was a uniquely painful yet meaningful experience.

May or may not have accidentally nuked the router, zfs pools, DNS, DNS resolution and docker containers at one point or another. Sometimes all of them at the same time.

Also between mismatched memory sticks and NVIDIA cards, I would debug the NVIDIA cards for future problems first. 18 cycles of memory training made little sense, but what was less intuitive to me was disabling CSM (compatability support module) to get a P2200 card to work with the B450M board the Debian server was on.

There are a couple of RPI 5 that I haven't gotten deciding what to set up in my small 10U rack and I'll update here as I eventually get to it.

To be honest, the homelab has been my way of diving headfirst into learning real-world networking and systems architecture outside of formal education, applying and testing concepts I come across.

Surprise surprise! Its just a bunch of PCs all along
Surprise surprise! Its just a bunch of PCs all along

Devices

Homelab Network Architecture

The homelab network is supposed to be logically and physically segmented from the main household (family) network to ensure isolation, control, and scalability. (also so that I can't accidentally take out my family's internet)

I'm not a professional or even trained in networking (at the time of writing 2025, I built this network from scratch through trial and error, googling, and begging ChatGPT for sources and examples to learn from - have never taken any courses or modules on networking yet)

Physical and Routing seperation

Homelab Network Segregation

The homelab network consists of multiple VLANs (802.1Q) and corresponding subnets carved out for different purposes. Each VLAN is isolated via tagged switch ports, firewall rules, and interface bindings.

Although the WireGuard tunnel lands in the 10.0.100.0/24 subnet, I use MikroTik's firewall and routing rules to control what internal VLANs can be accessed. No homelab subnets are exposed directly to the internet.

This was a pain to setup, so I recommend setting aside some time (and then multiply that planned time by 2) to sit down, plan and make sure each device connected via VLAN is properly configured.

VLAN ID Name Subnet Purpose Bound Interface
10 vlan10-servers 192.168.10.0/24 Main services (web apps, containers, internal APIs), mostly docker services ether2
20 vlan20-compute 192.168.20.0/24 Compute machines (Proxmox VMs) ether2
30 vlan30-NAS 192.168.30.0/24 NAS dedicated subnet (ZFS storage, NFS, iSCSI, SMB for homelab) ether2
40 vlan40-management 192.168.40.0/24 Management interfaces (IPMI, switch/router management IP) ether2
90 vlan90-internet 192.168.90.0/24 WAN access (uplink to Singtel ONR) ether2
110 vlan110-altserv 192.168.110.0/24 Alternate server subnet (testing nginx VLAN routing - failure) ether2
— wireguard1 10.0.100.0/24 Remote VPN access (WireGuard) wireguard1
— bridge 192.168.200.0/24 Default bridge (defconf; typically unused / fallback subnet) bridge
— ISP LAN 192.168.1.0/24 Family network (served by Singtel ONR) ether1

These VLANs are managed via:

Remote Access with WireGuard + AdGuard

To access my homelab securely from outside networks, I use WireGuard for VPN tunneling and route all DNS traffic through AdGuard Home, which uses Unbound for encrypted upstream resolution.

Apart from WireGuard which the router innately supports and acts as the server, AdGuard Home and Unbound (and PiHole which acts as a fallback for AdGuard) are uws independent Docker containers with their own IPs through the Debian Server on VLAN 10. 

                                    [Client Device]
                                              ↓ WireGuard VPN (10.0.100.x)
                                    [MikroTik Router]
                                              ↓ VLAN Routing
                                    [AdGuard Home (DNS)]
                                              ↓
                                    [Unbound (DoT upstreams)]
WireGuard provides a fast and lightweight tunnel into the 10.0.100.0/24 subnet (interface wireguard1), routed internally by MikroTik. Each device is manually added via public key, and only the WireGuard port (UDP 51820) is exposed to the internet.

All DNS requests over VPN are handled by AdGuard Home, which blocks ads, trackers, telemetry, and malware. It forwards queries to Unbound, which uses DNS-over-TLS (DoT) to upstream providers. This gives me a secure and ad-free browsing experience, even on public Wi-Fi.

With this setup, I can access self-hosted services like Proxmox, TrueNAS, Gitea, and Docker UIs from anywhere, without exposing them to the public internet.

On my phone, the WireGuard tunnel is permanently active — traffic is always routed through my homelab. On my Windows laptop, I toggle the connection using the WireGuard GUI client. On Linux, I manage it using wg-quick for a minimal CLI-based approach.

Homelab Upgrade Roadmap

While the current homelab setup is stable and operational, I have a long-term roadmap focused on scalability, service uptime, physical infrastructure, and secure external access. This roadmap is driven by experimentation, curiosity, and a desire to reduce failure domains while staying in control of every service.

Physical Infrastructure

  • Transition from the current 10U MikroTik SR-10U to a full-depth 20U or 40U rack with improved airflow and cable management.
  • Add a rack-mounted UPS to prevent data loss and allow for graceful shutdowns across critical services during power outages.
  • Standardize rack layout with proper labeling, patch panels, and side/rear cable routing.

Network Upgrades

  • Complete migration to the MikroTik RB5009UG+S+IN as the core router with VLAN-aware firewall rules and faster routing capacity.
  • Consider an upgraded Router after the RB5009 like the CCR2004 or entierprise switches

  • Look into replacing the generic 2.5Gbps switch with MikroTik CRS-series switches for better VLAN tagging, consistency, and monitoring.
  • Subscribe to a 10Gbps fiber plan to fully utilize RB5009’s capabilities and reduce upstream bottlenecks.

External Access & Security

  • Deploy a VPS-based reverse proxy (e.g., Hetzner) to tunnel traffic into the homelab via WireGuard.
  • Look into dedicated firewall devices, both enterprise (e.g. Cisco, Fortinet) and open-source (e.g. OPNsense, pfSense) (or even the forbidden virtualised firewall route)
  • Self-host selected services (e.g.Gitea, Jellyfin, dashboards, email) via subdomains routed through the VPS.
  • Ensure all outbound traffic from sensitive services like qBittorrent pass through a VPN killswitch using NordVPN to avoid IP leaks.
  • Begin exploring Zero Trust architecture for access control, identity-based access, and device trust posture enforcement.
  • Maybe consider looking into hardware authentication for access control as well

Service Architecture

  • Increase use of Proxmox for service separation via LXC containers and VMs.
  • Move toward either Docker Swarm or consider Kubernetes (K3s) to maintain consistent uptime, make service recovery easier, and support future scaling.
  • Break out critical services (AdGuard, Unbound, monitoring tools) onto a dedicated Raspberry Pi 5 for higher availability and role separation.

Philosophy: One Purpose per Device vs General Purpose

  • Borrowing from the UNIX philosophy of "Write programs that do one thing and do it well."
  • Experimenting with a philosophy of one device per critical role (DNS, VPN, monitoring) for fault isolation and simplicity.
  • In parallel, maintain general-purpose nodes (e.g., Proxmox or Docker hosts) for scalable, fast-to-deploy services.
  • This approach should balance resource efficiency with clean service boundaries.

← Back to Home