Secure Remote Access Design with Tailscale and WireGuard

Environment

Problem

I originally used a manually managed WireGuard setup for remote access, but it was slower, less reliable, and required more manual configuration across devices. I needed a remote access design that would let me securely manage the lab from anywhere without depending on exposed ports, inconsistent connectivity, or higher operational overhead.

Approach

I moved from a traditional manually configured WireGuard deployment to Tailscale, which still uses WireGuard encryption underneath but simplifies peer discovery, authentication, key handling, and connectivity between devices. The design focused on creating secure encrypted access to internal systems whether I was at home or on an outside network, while also extending access into internal lab subnets through Tailscale subnet routing.

This let me treat remote access as a controlled overlay on top of the existing homelab instead of as a set of individually exposed internet-facing services. It also made the design more practical to maintain across Proxmox, TrueNAS, Raspberry Pi, multiple lab nodes, my laptop, and my phone.

Implementation

• Deployed Tailscale on Proxmox, TrueNAS, Raspberry Pi, Nodes 100-109, laptop, and phone.
• Used Tailscale's WireGuard-based encrypted tunnels to secure communication between remote devices and internal lab systems.
• Configured subnet routing so remote devices could reach internal lab networks through designated Tailscale-connected nodes.
• Used the overlay network to maintain secure access to infrastructure even when away from home.
• Avoided exposing services directly to the internet, reducing attack surface compared to a port-forwarded design.
• Used the setup to securely route traffic across untrusted networks, such as public or external Wi-Fi connections, through an encrypted channel.
• Identified DNS complications caused by Tailscale MagicDNS, especially where its resolver behavior interfered with the existing internal DNS structure.

Key Lesson

One of the biggest lessons from this project was that a secure remote access design depends on more than just encryption. The VPN itself can be strong, but reliability, routing behavior, DNS handling, and ease of administration all affect whether the design is practical in the real world. Tailscale preserved the security benefits of WireGuard while removing much of the manual complexity that made the original setup harder to maintain.

Validation

• Verified I could securely access lab systems from outside the house.
• Confirmed encrypted connectivity between remote client devices and internal Tailscale-connected nodes.
• Tested access across multiple systems including Proxmox, TrueNAS, Raspberry Pi, and service nodes.
• Confirmed subnet routing provided access beyond only directly installed Tailscale endpoints.
• Observed and troubleshot DNS issues related to MagicDNS and internal name resolution behavior.

Outcome

The final design gave me a more reliable and maintainable way to securely access the homelab from anywhere. Instead of relying on individually exposed services or a more fragile manually managed VPN configuration, I now use an encrypted overlay network that allows remote administration of infrastructure and internal systems while keeping the environment private.

It also improved security when connecting from outside networks by protecting traffic inside encrypted tunnels, which reduces the risk of interception on untrusted connections and keeps lab access consistent whether I am at home or away.

What I Learned

• WireGuard provides strong security, but managing it manually across many systems adds complexity.
• Tailscale simplifies encrypted connectivity while still using WireGuard as the underlying protocol.
• Subnet routing is useful for reaching internal networks without requiring every device to run a client directly.
• DNS behavior matters in overlay networks, especially when MagicDNS interacts with an existing DNS design.
• Reliable security design depends on routing, usability, and maintainability, not just encryption alone.

What I'd Improve Next

The next step would be refining the design with stricter access control and a clearer source-of-truth document for remote access paths, subnet routing behavior, and DNS expectations. I would also like to further document which nodes should act as routing points so that the design is easier to troubleshoot and scale as the lab grows.