On this page
Tailscale already uses WireGuard for its encrypted data plane. Using them “together” usually means combining Tailscale's identity-based network with a separate, manually managed WireGuard tunnel—not stacking two encryption layers on every packet.
A useful home-lab design gives laptops and phones Tailscale access while preserving a plain WireGuard path for a router or appliance. This walkthrough builds clear boundaries between those paths so routes, permissions, and troubleshooting stay understandable.
Draw three networks before installing anything
Choose distinct ranges for the home LAN, the manually managed WireGuard peers, and remote networks you commonly visit. For this example, the lab LAN is 192.168.50.0/24 and the separate WireGuard transit network is 10.77.0.0/24. Tailscale normally assigns addresses from its own 100.64.0.0/10 space; do not reuse that range for your manual tunnel.
Use the Subnet & CIDR Calculator below to verify network boundaries and whether each server belongs inside your proposed advertisement. The calculator identifies address classification, but it cannot discover overlapping routes on your machines. Route inventory still requires inspection.
Decide whether clients need one host, a whole subnet, or an internet exit. Those are different permissions. Access to a home dashboard does not require an exit node, and a subnet router need not expose every device on the LAN. Start with the smallest useful destination and expand only after a working test.
Pick a topology with independent paths
Install Tailscale directly on machines that support it. For devices that cannot run an agent, use an always-on Linux machine as a subnet router. A Raspberry Pi or small server can perform this role, provided it has reliable power, updates, and a stable LAN address.
The separate WireGuard gateway can run on another Linux host or router. Keeping the roles separate makes packet paths easier to inspect. If one server handles both, remember that interfaces alone do not create isolation: forwarding and firewall policy determine whether traffic crosses between them.
The Tailscale knowledge base explains coordination, direct connectivity, relays, subnet routers, and access controls. A relayed connection is not a different plaintext mode; it still carries encrypted tunnel traffic. Relay use can change performance, however, so do not assume every successful connection is direct.
For plain WireGuard, follow the official quick start for package installation and key generation. You normally need a reachable UDP endpoint, which may require router port forwarding. Carrier-grade NAT can prevent unsolicited inbound access; Tailscale's traversal and relay mechanisms are useful precisely because home connectivity is not always straightforward.
Bring up the Tailscale subnet route deliberately
On a dedicated Linux subnet router, enable IPv4 forwarding, then advertise only the lab prefix. Install and authenticate Tailscale using its supported instructions before running the following example. These commands assume the host is intentionally serving as a router, not a general workstation.
printf 'net.ipv4.ip_forward = 1
' | sudo tee /etc/sysctl.d/99-lab-router.conf
sudo sysctl --system
sudo tailscale set --advertise-routes=192.168.50.0/24
tailscale statusAdvertising is not enough: approve the route in the administrative console unless an appropriate auto-approver policy already exists. Restrict access with grants or ACLs, rather than assuming route approval is a user authorization boundary. Default tailnet policy may permit broader access than you intend.
Linux clients generally need to opt in to accepting advertised subnet routes; other supported clients commonly accept them by default. Check the relevant platform settings instead of repeatedly changing the router. A client that already sits on 192.168.50.0/24 may prefer its connected LAN route, which makes a local test misleading.
Tailscale subnet routers use source NAT by default. LAN servers therefore commonly see the router's address rather than the original tailnet client address. Disabling that behavior requires return routes and additional planning. Keep the default initially unless preserving source addresses is a defined requirement.
Add a narrow manual WireGuard peer
The manual tunnel should have its own keys and nonoverlapping addresses. This client configuration gives one appliance access to the lab without changing its default internet route. Replace every key placeholder and the documentation endpoint before use; the endpoint shown is intentionally not a live server.
[Interface]
Address = 10.77.0.2/32
PrivateKey = <CLIENT_PRIVATE_KEY>
[Peer]
PublicKey = <GATEWAY_PUBLIC_KEY>
Endpoint = 203.0.113.10:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32
PersistentKeepalive = 25On the gateway, assign 10.77.0.1/24 and configure the client's peer with AllowedIPs = 10.77.0.2/32. The AllowedIPs setting controls peer selection and accepted source addresses; it is not a substitute for a service firewall. Permit only the required forwarded traffic between the WireGuard interface and the LAN.
For return traffic, either add a LAN router route for 10.77.0.0/24 through the WireGuard gateway or deliberately configure narrowly scoped source NAT on that gateway. Without either, initial packets may reach a server while replies disappear through its default gateway. The Linux IP sysctl documentation describes forwarding behavior and related kernel settings.
Do not put Tailscale addresses into this peer's broad route set simply to “connect everything.” That creates a transit design requiring explicit authorization and bidirectional routing, not a harmless convenience setting.
Verify routes and restrict services
Test from a phone using cellular data rather than home Wi-Fi. First reach the Tailscale node itself, then one approved LAN service. Test the manual WireGuard client separately. Independent tests distinguish an overlay problem from a LAN firewall or return-route problem.
ip route get 192.168.50.20
tailscale ping lab-router
sudo wg showReplace lab-router with your node name. A recent WireGuard handshake confirms peer communication, not application health. Check the destination port and host firewall next. Avoid publishing management interfaces on the public internet as a workaround for a routing issue.
Use the CIDR planning tool when adding a second site, and compare its LAN range with all existing routes. The split-tunneling guide explains why local printer access and remote prefixes can conflict. For least privilege, grant a named user access to a dashboard port before considering an entire subnet.
Keep a short runbook listing the advertised prefixes, gateway addresses, approved services, and expected return paths. Include a known-good local login method so a mistaken remote policy does not lock you out of the lab.
Document ownership, device removal, recovery access, and key rotation. Lost phones should be revoked from the tailnet; retired manual peers should be removed from the WireGuard gateway. Neither path should survive indefinitely just because it once worked.
Key takeaways
- Treat Tailscale and manual WireGuard as separate access paths, not mandatory nested tunnels.
- Reserve nonoverlapping ranges and advertise only necessary destinations.
- Route approval and user authorization are separate controls on a Tailscale subnet router.
- Manual WireGuard access needs gateway forwarding, service rules, and a working return path.
- Test from outside the LAN and remove obsolete devices from both systems.
Reach designers & developers at work
Put your product next to the tools people use every day. One sponsor per placement, no tracking pixels.
Become a sponsor