WireGuard or Tailscale for reaching your homelab

Your homelab is at home, and you are not. Between you and the dashboard sits a router that, quite sensibly, does not talk to strangers. Two tools get you in without leaving the front door open to the whole internet.

The short answer

WireGuard is the tunnel. Tailscale is a service built on WireGuard that adds key handling, connection setup through NAT, access rules and device names [1][5]. Our assessment: use plain WireGuard if you have one gateway that is reachable from outside, only a few devices, and you want no third party in the path. Use Tailscale if your home connection cannot take incoming connections, if the device list keeps growing, or if you want rules per user and per device. Many homelabs end up using both. Neither replaces patches and logins on the services behind it.

How it works

1. What WireGuard is. WireGuard packs IP packets into encrypted UDP. You add a network interface, give it your private key and the public keys of your peers, and send packets through it. Distributing keys and pushing configurations are explicitly out of scope, in the style of SSH [1]. Its central idea is cryptokey routing: each peer has a public key and a list of AllowedIPs. When sending, that list acts like a routing table. When receiving, it acts like an access list, because a packet from that peer with any other source address is dropped [1]. The design avoids answering unauthenticated packets, which the author describes as making WireGuard invisible to scanners [3].
2. What you do yourself. You create a key pair per device. The Quick Start shows umask 077, then wg genkey | tee privatekey | wg pubkey > publickey [2]. You write a configuration per device, and wg-quick up wg0 reads /etc/wireguard/wg0.conf and sets up interface and routes. wg-quick down wg0 removes them again [4]. You also make sure the peers can reach each other. WireGuard secures the traffic between two devices but does not make sure they can connect. You may need a port forward on the router, and a tunnel that stays quiet behind NAT needs PersistentKeepalive, for which the Quick Start suggests 25 seconds [2][5]. Every pair of devices needs an entry, so a fully meshed setup grows quadratically with the number of devices [5].
3. What Tailscale adds. You install the client and log in. Tailscale then distributes the keys and configuration [5]. On Linux that is curl -fsSL https://tailscale.com/install.sh | sh followed by sudo tailscale up, which prints a login URL [10]. The devices form a "tailnet". Tailscale tries to connect them directly through NAT without port forwarding, and relays encrypted traffic when that fails. Two devices on the same LAN talk locally [5]. The data layer is WireGuard, and Tailscale says its private keys never leave the device, so Tailscale cannot decrypt the traffic [5].
4. Relays and firewalls. The relay servers are called DERP. They help set up connections and are the last fallback. They forward traffic that is already encrypted [6]. tailscale status shows per device whether a connection is "direct" or goes over a "relay" [7]. Tailscale says that most of the time you do not need to open any firewall port. It does expect outgoing TCP 443, outgoing UDP from source port 41641 (the default, configurable) and outgoing UDP 3478 for STUN [7].
5. Reaching things that cannot run a client. A printer or a NAS web page cannot run Tailscale, but a Linux box next to them can act as a subnet router. You enable IP forwarding, advertise the route and approve it in the admin console. By default the router rewrites the source address, so traffic from behind it looks like it comes from the router. Devices behind a subnet router do not count against the device limit of a plan [8]. A subnet router is not an exit node. An exit node sends your internet traffic through that machine, a subnet router only opens specific private networks [8].
6. Names and rules. Tailscale offers MagicDNS names and access rules written once for users, groups and tags [5]. With plain WireGuard you get the same effect only by not setting up tunnels between devices that should not talk, plus the firewall of the operating system [5].
7. Whom you trust. With Tailscale the control plane can add and remove nodes. Tailnet Lock lets your own trusted nodes sign new nodes, following a trust-on-first-use model. As of the page's last validation on 2 Dec 2025 it was available on the Personal and Enterprise plans [14]. You can also host the control plane yourself with Headscale, an open source reimplementation for a single tailnet that is not associated with Tailscale Inc. and whose README says it does not support or encourage reverse proxies and containers for it [17]. Login goes through an identity provider such as Apple, Google, GitHub, Microsoft, Okta or OneLogin, or a custom OIDC provider. There are no Tailscale passwords and no sign-up by email, and a tailnet cannot be moved from or to GitHub or Apple as provider [15].
8. Speed. Tailscale's own comparison page says that WireGuard on its own is faster. The most visible difference is on Linux, where WireGuard can run as a kernel module and Tailscale at the time used the userspace implementation. A relayed Tailscale connection is slower than a direct one [5]. That page also contains statements dated December 2020, so measure on your own hardware. Our assessment: for a home line, the uplink limits you before the tunnel does.
9. Cost. WireGuard is free software. As of 24 Oct 2026 Tailscale's pricing page lists a Personal plan at no cost, for up to 6 users with unlimited user devices, and a Standard plan at $8 per user per month [16]. Plans and prices change, so check the page. We did not check whether the Personal plan's terms cover commercial use. Read them first if you use it for a business.
10. Key lifetime. Tailscale devices must log in again after 180 days by default. You can disable expiry for servers, and devices you tag for the first time have it off by default [13]. An expired key silently ends connections, so a server you reach from far away should not depend on it. A static WireGuard key does not expire. It also does not rotate by itself, so replacing it is your job (our assessment).
11. Can your line take incoming connections? Plain WireGuard needs one endpoint that others can reach. If your provider shares IPv4 addresses between customers, which is what Dual-Stack Lite does [18], you cannot expect to forward a port for incoming IPv4 (our reading). The options are an IPv6 endpoint or a small rented server as hub. Look at your router's status page before you plan. Tailscale needs no incoming port [5][7].
12. What speaks against each. WireGuard: every device is manual work, keys and endpoints are yours to keep in order, there is no user management or central log, and an open UDP port at home is a permanent exposure that you patch. Tailscale: a third party sits in the control path, you depend on an account with an identity provider, relays cost speed, and the free plan has limits that can change. Both: a tunnel into your LAN gives a stolen laptop the same reach, so limit what the tunnel may reach.

Side by side

A homelab example

On 14 Oct 2026 we decided that a phone should reach the Bytearium home network over WireGuard on our UniFi gateway, as a split tunnel that carries only home-network traffic. The gateway sits behind the internet provider's router (double NAT). That is why a UDP port forward on that router, a dynamic-DNS name for the endpoint and a check for a public IPv4 address, not Dual-Stack Lite, come first. On the phone the allowed addresses cover only the home network and the tunnel network, the DNS field stays empty so name lookups on the phone are untouched, and the tunnel starts by itself on mobile data and foreign Wi-Fi but not at home. We have not recorded whether the tunnel is set up yet, and Tailscale does not appear in our inventory (state 14 to 18 Oct 2026). What follows is a general walkthrough for your own Linux server, not a report from ours.

Plain WireGuard, one server and one laptop. Choose a tunnel network that does not overlap your LAN, here 10.8.0.0/24. The structure follows the project's own example [1][4]:

# server: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server-private-key>

[Peer]
# laptop
PublicKey = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

# laptop: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.2/24
PrivateKey = <laptop-private-key>

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.org:51820
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24
PersistentKeepalive = 25

The laptop's AllowedIPs names only the tunnel and the home LAN, which makes it a split tunnel. A value of 0.0.0.0/0 would send everything through home, and wg-quick then handles the default route for you [4]. Start with sudo wg-quick up wg0 and look at sudo wg show. To let the laptop reach other machines on the LAN, the server must forward packets, and those machines need a return route to 10.8.0.0/24 or the server must rewrite source addresses. The PostUp and PostDown keys of wg-quick are the place for such firewall rules [4].

Tailscale as subnet router on a Linux server. The commands follow Tailscale's documentation [8][10]. Replace 192.168.10.0/24 with your LAN:

curl -fsSL https://tailscale.com/install.sh | sh
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale up
sudo tailscale set --advertise-routes=192.168.10.0/24

Then approve the route on the Machines page of the admin console, add an access rule that allows your user to reach the subnet, and check from another device with tailscale ip -4 on the router and a ping. Linux clients only pick up subnet routes with sudo tailscale set --accept-routes [8]. Tailscale advises that your firewall should deny forwarding by default before you enable IP forwarding [8], and that you consider disabling key expiry on the server [13].

Tailscale in Docker, as a node for a container stack, with a pinned tag that exists on Docker Hub as of 24 Oct 2026 [12]. The setup follows Tailscale's standalone Docker example [9] and parameter list [11]. Create the auth key in the admin console, keep it in a .env file as TS_AUTHKEY=..., and treat it like a password:

services:
  tailscale:
    image: tailscale/tailscale:v1.104.2
    hostname: homelab-node
    environment:
      TS_AUTHKEY: "${TS_AUTHKEY}"
      TS_STATE_DIR: "/var/lib/tailscale"
    volumes:
      - "./tailscale-state:/var/lib/tailscale"
    cap_add:
      - net_admin
      - net_raw
    restart: unless-stopped

Without the state directory every restart creates a new node in the admin console [11]. The container runs in userspace networking by default, which works everywhere but is slower than kernel networking [11].

Checklist

• Check whether your connection takes incoming connections at all, using your router's status page, before you choose.
• Decide who needs access: only you, or family and friends too. The answer favours WireGuard or Tailscale accordingly.
• Choose a tunnel network that does not overlap your LAN, and keep AllowedIPs as narrow as the job allows.
• Generate keys with umask 077 and keep private keys off shared drives and out of the repository.
• Forward only the one UDP port WireGuard needs, never a whole host.
• Set a firewall rule that denies forwarding by default before you turn on IP forwarding.
• Write rules in Tailscale that name users, groups or tags, and test them with a device that must be denied.
• Check key expiry on every Tailscale server and decide whether it should be off.
• Pin the Docker tag, write down the date, and read the release notes before you change it.
• Test the way back: switch off the tunnel on your phone and confirm that you cannot reach the LAN.
• Note who can reach what, and remove devices you no longer use.