# Private networking between your VPSes (Tailscale or WireGuard)
Source: https://vpsdime.com/knowledgebase/technical-questions/private-networking-between-vpses
Last reviewed: 2026-07-05
Summary: We don't provide built-in VLANs, and the recommended pattern is better anyway: an encrypted overlay network between your servers. Tailscale as the ten-minute path (with your laptop joining too), plain WireGuard as the self-hosted path, Headscale in between, and how binding services to the overlay replaces public exposure entirely. Plus the MagicDNS gotcha: Tailscale pointing resolv.conf at 100.100.100.100 can break a server's DNS, fixed with --accept-dns=false or disabling MagicDNS.

## What this is

You have two or more servers, a web VPS and a database VPS, an app and its workers, and they need to talk **privately**. We don't provide built-in private VLANs; the pattern we recommend instead is an **encrypted overlay network**, and it's genuinely the better tool: it's encrypted end to end, it works **across our locations** (and to servers elsewhere, and to your laptop), and services bound to it are [never exposed to the public internet at all](https://vpsdime.com/knowledgebase/getting-started/securing-public-services).

One clarification worth making: our [edge firewall already trusts traffic between your own VPSes](https://vpsdime.com/knowledgebase/client-area/services/firewall) (no whitelisting needed for the blocked app ports), but that's a *firewall* convenience, the traffic still crosses the network unencrypted, on public IPs. The overlay adds what that can't: **encryption, plus stable private IPs** that survive [migrations](https://vpsdime.com/knowledgebase/getting-started/migrating-a-vps) and IP changes.

## Option A: Tailscale, the ten-minute path

[Tailscale](https://tailscale.com/) builds a WireGuard mesh for you, key exchange, NAT traversal, and IP management handled. On **each** server:

```
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up
```

Authenticate each with the same account (the free tier comfortably covers a personal fleet), and every machine gets a stable **100.x.y.z** address plus a DNS name (MagicDNS), reachable from every other machine on your tailnet, and nothing else. The quiet superpower: **install it on your laptop too**, and you can reach every server's private services from anywhere, without a single public port, [databases, panels](https://vpsdime.com/knowledgebase/getting-started/securing-public-services), all of it.

The trade-off to name honestly: Tailscale's coordination server is a third party (the traffic itself is end-to-end WireGuard; they broker keys and connections). If that's a dealbreaker, **[Headscale](https://headscale.net/)** is the open-source, self-hostable control plane the Tailscale clients can use instead, or go one layer down:

## Option B: plain WireGuard, the self-hosted path

For a small, static set of servers, [WireGuard](https://www.wireguard.com/) by hand is simple enough to be worth owning, no third party, nothing to trust but your own configs. Two servers:

```
apt install wireguard
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
```

`/etc/wireguard/wg0.conf` on server A (`10.10.0.1`):

```ini
[Interface]
Address = 10.10.0.1/24
PrivateKey = <A's private key>
ListenPort = 51820

[Peer]
PublicKey = <B's public key>
AllowedIPs = 10.10.0.2/32
```

Server B mirrors it (`Address = 10.10.0.2/24`, peer = A's public key, plus `Endpoint = A.PUBLIC.IP:51820` and `PersistentKeepalive = 25`). Then on both:

```
systemctl enable --now wg-quick@wg0
```

Allow **UDP 51820** in the listening server's own firewall, and `ping 10.10.0.1` from B proves the tunnel. Each extra server is another `[Peer]` block, which is also the honest scaling limit: past a handful of nodes, the config bookkeeping is exactly what Tailscale exists to remove.

## Using the overlay (the actual point)

Once every server has its private address, **bind internal services to it instead of to public IPs**:

- MySQL for the app server only: `bind-address = 10.10.0.1` (or the Tailscale IP), the port simply doesn't exist publicly, no [whitelist](https://vpsdime.com/knowledgebase/client-area/services/firewall) needed.
- [NFS](https://vpsdime.com/knowledgebase/technical-questions/enable-nfs), Redis, RabbitMQ, [Docker Swarm](https://vpsdime.com/knowledgebase/technical-questions/docker-swarm) overlay traffic, everything trusted-network-shaped now has a trusted network.
- Latency between your servers is [the path's latency](https://vpsdime.com/knowledgebase/troubleshooting/network-problems) plus a negligible encryption cost, same-location VPSes feel LAN-like.

## Troubleshooting: DNS problems after enabling Tailscale (MagicDNS)

With **MagicDNS** enabled on the tailnet (it's on by default), Tailscale takes over the server's DNS: `/etc/resolv.conf` is rewritten to point at **100.100.100.100**, Tailscale's own resolver, which answers tailnet names and forwards everything else upstream. That's what MagicDNS is; finding that address in your `resolv.conf` is the sign it's active.

On a server, this handover can break normal name resolution. A real case from support: a customer running **sshfs over Tailscale** saw intermittent login and resolution failures, and the cause turned out to be MagicDNS having taken over the server's DNS. Disabling it fixed the problem.

A VPS doesn't need Tailscale managing its DNS, it has a working resolver of its own, and other machines can still reach the server by its Tailscale IP. So if resolution misbehaves and `resolv.conf` shows `100.100.100.100`:

- **Tell Tailscale to leave DNS alone on that server:** `tailscale up --accept-dns=false`. The machine stays on the tailnet; its resolver config stays its own.
- **Or disable MagicDNS for the whole tailnet** in the Tailscale admin console, under the **DNS** tab.
- If `resolv.conf` was left pointing at `100.100.100.100` with resolution dead, put a real nameserver back (for example `nameserver 1.1.1.1`) to recover immediately, then apply one of the two fixes above so it doesn't come back.

## Still need help?

You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning:

- the servers involved (hostnames or IPs),
- Tailscale or plain WireGuard,
- where the tunnel fails (handshake, ping, or binding a service to it).

## Related questions

- "How do I connect two VPSes privately?"
- "Do you offer private networking or VLANs?"
- "Tailscale or plain WireGuard for connecting my servers?"
- "How do I make my database reachable only by my other VPS?"
- "Can my laptop join the same private network as my servers?"
- "Why did DNS stop working on my VPS after enabling Tailscale?"
- "What is 100.100.100.100 in my resolv.conf?"
- "How do I stop Tailscale from changing my DNS settings?"