Homelab

Remote Access with WireGuard + AdGuard

For remote access, I use a small VPS as a public WireGuard edge gateway. This solves a few annoying residential network problems at once: double NAT, possible CGNAT, and ISP IP rotation.

Instead of exposing the homelab directly (remember not a reliable IP because of ISP behaviour), the router maintains an outbound WireGuard connection to the VPS. Remote peers also terminate on the VPS, and traffic is then forwarded into the homelab based on the WireGuard interface design and firewall rules. I split access by interface as well, so admin and guest peers do not get the same reach into the internal VLANs.

        [Remote Peer]
        ↓ WireGuard 
        [VPS]
        ↓ Forwarding Rules to Seperate Tunnel
        [MikroTik Router]
        ↓ VLAN Routing + Firewall Policy
        [Internal VLANs / Services]
        ↓ Internet Traffic
        [AdGuard Home (DNS)]
        ↓
        [Unbound (DoT upstreams)]
    

The intermediary VPS layer helps to solve a couple of problems. One of which is the frequent switching (rotation) of residential IPs by the ISP, solving the issue of double NAT (I did not want to replace the ISP router with my own -- My family still uses the regular ISP network), potential CGNAT issues, and a static IP my domain can point to. It's a cheap 5 dollar/month nanode that purely handels this network filtering and forwarding job. The peer list is still quite small and managable, but I might look at automating it via git changes, though some form of secrets generation and replacement (maybe hashicorp valut) might be needed.

The VPS also terminates separate WireGuard interfaces for different roles. There is an admin interface for full internal access, a guest interface with restricted VLAN reach, and a backhaul interface linking the VPS to the homelab router. From there, traffic is routed and filtered into the internal network using WireGuard peer design, MikroTik routing, and firewall rules. No internal VLANs are exposed directly to the public internet.

In practice, this means the VPS acts as a public entry point, policy boundary, and transit hop rather than a machine that actually hosts the services themselves. It is mostly there to provide a static IP, terminate the tunnels, and forward permitted traffic onward to the homelab.

All DNS requests over VPN are handled by AdGuard Home, which tries to block ads, trackers, telemetry, and malware. It forwards queries to Unbound, which uses DNS-over-TLS (DoT) to upstream providers. This on paper 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 Potential Upgrades

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

• Considering a migration from the current 10U MikroTik SR-10U to a 20-40u 1000mm depth rack for improved airflow and cable management. Looking at some 800x1000mm 36u rack to fit forseable hardware needs.
• Add a rack-mounted UPS to prevent data loss and allow for graceful shutdowns across critical services during power outages. Possibly using NUT to control the UPS behaviour
• Building a central permament 2-4u virtualisation server using either a Rome or Milan chip to take advantage of the enterprise/datacenter hardware decomissioning cycle (hope DDR4 rdimm becomes cheaper in bulk).
• Additional 1-4u servers based on needs, like NAS expansion, dedicated public facing services server, more proxmox nodes for HA (consensus voting)
• Standardize rack layout with proper labeling, patch panels, and side/rear cable routing.
• When the enterprise upgrade/decomission cycle for LTO-8 is due, I plan to add an additional layer of tape archives on top of my NAS, to keep them in a different format and for long term storage.

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.
• It is looking more like K3s since the recommended running for AWX involves AWX Operator, and having ran it via Rancher, it looks promising

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.