Connecting sites: VPN, Tailscale, NetBird or Cloudflare Mesh?

I spend a lot of time working on connectivity between business networks. The same questions come up regularly: What is the best way to connect our sites? Do we need public IP addresses? How secure is it? And will the solution still fit when another branch, a different internet connection or more employees come along?

My answer depends on what the business actually needs. Two fixed sites with existing firewalls have different starting points from several small branches on changing connections. There are also questions beyond the tunnel itself: who operates it, where access is controlled and which dependencies the business is prepared to maintain.

That is why I want to understand the architecture before choosing a product. A traditional site-to-site VPN can be a good fit. Tailscale or NetBird can simplify management and connection setup. Cloudflare Mesh moves the traffic path into the provider’s network. Those differences shape where each approach makes sense to me.

The focus here is connecting whole site networks. I discuss access for individual employees working from home separately as an additional remote-access use case.

Our example: Three connected site networks

Headquarters uses 10.1.0.0/24, the branch uses 10.2.0.0/24 and the home lab uses 10.3.0.0/24. Each site gets a gateway that makes remote networks reachable. Printers and NAS devices behind it do not need their own VPN clients. Every model in this comparison serves the same goal: controlled connectivity between these three site networks.

This creates a routed Layer 3 network. The sites do not automatically share a broadcast domain, and local discovery protocols do not all start working across locations. DNS must resolve internal names appropriately, and local routers need routes to remote networks.

When choosing a solution, I first want to know which network needs which services. The branch might need the file server without access to home lab administration. The backup server needs its backup destination without access to every device at the other site. Every option still requires these decisions.

Site-to-site describes the connection, not the topology

Site-to-site means network to network. It does not require all traffic to pass through a central firewall. Hub-and-spoke through headquarters is a common topology; direct tunnels between pairs of sites also provide site-to-site connectivity. The site gateways used by Tailscale, NetBird or Cloudflare Mesh can serve that same purpose.

Tailscale and NetBird aim for direct data paths even when enrolment and coordination are managed centrally. Cloudflare’s provider network is geographically distributed, but site traffic still traverses Cloudflare. This is not a direct peer-to-peer connection between sites. The provider network replaces your central firewall as the transit point.

Public IPs and changing requirements

The public IP question tends to come up early. I separate two issues: whether a connection is reachable from outside and whether its address remains the same. A fixed public address simplifies planning for a reachable VPN endpoint. It is not required at every site, however. A branch can establish an outbound tunnel to a reachable central gateway; depending on the design, dynamic DNS can help with changing addresses too.

It becomes harder when both ends sit behind restrictive carrier-grade NAT without a directly reachable endpoint. For mobile internet connections in particular, check which addresses and inbound connections the provider actually supports. Tailscale and NetBird attempt direct connectivity through NAT and can use relays when necessary. Cloudflare Mesh instead establishes outbound connections to the provider network.

I also want the next change to remain manageable. An additional site, a provider change or a connection without inbound reachability can turn a modest configuration into a different task. That does not mean replacing a working solution in advance. It does mean considering these possibilities before committing to a topology.

Traditional site-to-site VPN: The gateways handle it

Two firewalls or routers establish an encrypted tunnel, often using IPsec or manually configured WireGuard. Local routing sends traffic for the remote network into that tunnel. The other gateway decrypts the packets and forwards them into the destination network.

With three sites, headquarters can act as the hub. The branch and home lab each connect to it. This simplifies the topology but sends traffic between those two locations through headquarters. A full mesh connects every pair directly. For n sites, that means n × (n − 1) / 2 connections: three for three sites, already 45 for ten. Controllers and dynamic approaches can reduce the work; traditional VPNs are not limited to manually configured hub networks.

Benefits: This fits existing firewalls and clear site boundaries. You control the tunnel endpoints. There is no additional mesh provider in the traffic path, and routing, rules and logging can fit existing administration.

Drawbacks: Routing, key management and operational work grow with the number of sites. NAT, changing internet addresses and different vendors can complicate troubleshooting. Mobile users often require a separate remote-access setup.

A fixed public address at every site is not a universal requirement. A reachable hub with outbound connections from the branches is enough in many configurations. Dynamic DNS and NAT traversal can also help. When both ends sit behind restrictive CGNAT, however, direct connectivity becomes harder without a reachable endpoint or intermediary.

For two stable sites with suitable firewalls, this remains a sensible choice. A working VPN does not need replacing simply because another product presents fewer configuration fields.

Tailscale: Direct connections with central coordination

Tailscale adds device enrolment, coordination and access policies to WireGuard. Its control service helps participants find each other. Traffic flows directly between peers whenever possible. When NAT or firewall restrictions prevent that, a relay can provide a path. Traffic remains encrypted between Tailscale peers even through a DERP relay.

Subnet routers connect whole LANs to the tailnet. Tailscale’s documented site-to-site scenario uses Linux at both tunnel endpoints. Devices behind them need no agent but still require appropriate routes. Preserving original source addresses by disabling source NAT makes planning the return path particularly important.

Benefits: Existing LAN devices can participate through subnet routers. Direct connections between these gateways avoid a mandatory detour through a central site. Additional individual user devices can join through the same platform.

Drawbacks: A direct path is not guaranteed. Relay paths can have different latency and throughput. The hosted coordination service remains an operational dependency, and the plan and feature set must fit the deployment.

WireGuard encryption ends at the participating peer. If that peer is a subnet router, the following LAN segment sits outside that tunnel. HTTPS or SSH therefore remain useful inside the private network.

NetBird: A similar mesh with a self-hosting option

NetBird also builds on WireGuard, attempts direct peer connections and uses relays when necessary. Routing peers connect networks whose devices do not run a client. The current site-to-site guide describes Networks, Resources and corresponding access policies.

Benefits: The open-source project offers a self-hosted alternative to its cloud service. That matters when infrastructure and management need to remain under your responsibility. Groups and policies help restrict access deliberately.

Drawbacks: Self-hosting brings responsibility for updates, backups, monitoring and the availability of coordination and relay services. A quick installation does not remove that work. The documented Networks site-to-site design keeps masquerading enabled, so the destination does not simply see the original source address. Other routing approaches need separate planning.

Tailscale and NetBird are close relatives, but their configurations are not interchangeable. I would evaluate both against the required routing and identity model. Open source also does not mean every product feature has unrestricted licensing: check the licences and features required for the intended deployment.

Cloudflare Mesh: The provider network becomes the path

Cloudflare Mesh participants establish outbound connections to Cloudflare. Traffic between sites traverses its network. You do not need to connect every site directly to every other site or operate your own central VPN hub. The trust boundary and traffic path nevertheless differ from a direct WireGuard mesh.

Benefits: The approach combines connectivity with central Gateway policies. It can fit particularly well where Cloudflare One already serves the environment. Sites behind NAT and mobile clients can join using outbound connections.

Drawbacks: Operation and traffic paths depend on the provider. Cloudflare’s processing must fit the trust and privacy requirements for sensitive data. Application protection through TLS or SSH remains useful. Whether the path benefits a particular application requires measurement; a global backbone does not prove better performance everywhere.

For a new deployment, I would follow the currently documented client approach. Cloudflare labels Mesh as Beta and requires MASQUE in the Mesh node device profile. The provider documents limitations for high availability, IPv6 and hostname routes when using WireGuard. A router supporting WireGuard is therefore not enough on its own to treat it as an equivalent Mesh node.

Cloudflare Mesh should also be distinguished from a cloudflared tunnel for individual applications. This example concerns bidirectional private IP connectivity between participants and routed networks.

The differences at a glance

These are the differences I weigh first when choosing a solution. The required subscription and actual connection path still need checking for the specific environment.

What I expect from secure site connectivity

When asked which solution is safest, I first look at permitted connections and access management. An encrypted tunnel can still allow far more access than it should. I want to define which networks can reach which services, how administrators are protected and how access can be revoked. MFA for administration and personally enrolled users, limited permissions and maintained gateways all belong in that assessment.

The encryption boundaries differ too. A traditional VPN tunnel ends at the site gateways. Tailscale and NetBird establish WireGuard connections between peers, which may be subnet routers. The following LAN segment is not automatically encrypted. With Cloudflare, processing inside the provider network must also fit the business requirements. HTTPS or SSH remain useful for the application itself.

An outbound connection can simplify setup and avoid a publicly reachable VPN service at the branch. It does not replace an access policy. Equally, a public IP does not automatically make a firewall insecure. The services actually exposed, their protection and ongoing operation determine the risk. I do not derive a security ranking from product names alone.

What I want to verify before acceptance

Site connectivity needs working paths in both directions. The route to 10.2.0.0/24 belongs on the responsible router or client. If the destination replies through another default gateway, the return direction needs an appropriate route too. SNAT can simplify replies but changes the visible source address, affecting logs and policies. That should be a deliberate design decision.

For high availability, deploying two overlay nodes is not enough. LAN devices must still reach their next gateway after a failure. Keepalived and VRRP can provide a virtual gateway address, for example. Remote routes must also select a healthy node. During acceptance, I therefore want to see what happens to new and established TCP sessions when a gateway or its tunnel fails. A running tunnel process and a successful ping answer only part of that question.

Functional checks should also cover deliberately blocked connections. If SSH should be allowed and another application denied, that behaviour needs to be verifiable. A successful ICMP test says nothing conclusive about a TCP policy. Enrolment, access policies and the destination host firewall must agree.

Then there are the less visible details that still determine daily usability: distinct network prefixes, internal name resolution and the appropriate MTU. Neither 192.168.x.x nor 10.x.x.x guarantees a conflict-free network. Small pings succeeding while larger transfers stall would not make me consider the connection finished.

A meaningful performance comparison needs the same file transfer and interactive application over the actual internet connections. Record the direct or relayed data path, CPU utilisation and behaviour after an internet change too. My assessment here concerns architecture and operational differences; it does not provide a measured speed ranking of these products.

Remote access: Adding individual devices

When an employee connects a laptop from home to the company network, that is remote access or client-to-site. The client runs on the laptop; it does not automatically connect the employee’s entire home network to headquarters. This can use a remote-access service on the central firewall or the clients offered by the platforms compared here. A personally enrolled client can also have permissions tied to users and groups.

A home office can instead be a site-to-site location: a gateway there connects an approved network or VLAN to headquarters. The distinction is therefore not whether someone works at home or in a branch. It is whether you connect an individual device or a network. Remote access often provides the more appropriate scope for individual employee devices. There is no reason to make the entire private home network reachable without that being intended.

Where each approach makes sense to me

For a few fixed locations with existing firewalls, I would start with traditional VPNs and deliberately choose between hub-and-spoke and direct tunnels. For sites behind NAT and centrally managed connectivity with direct data paths where possible, I would compare Tailscale and NetBird. When operating the control service yourself is a firm requirement, NetBird belongs early in that evaluation. Where Cloudflare One policies already exist, I would examine Cloudflare Mesh, including its Beta status and processing in the provider network. Additional remote access is a separate selection criterion.

Headscale is another option worth considering: a self-hosted implementation of the Tailscale coordination server. It is a separate project with its own feature coverage, rather than a complete replacement for every hosted-service capability. Manually managed WireGuard already belongs to the traditional model and makes sense when a few tunnels are sufficient without another management layer.

When someone asks me for the best solution, I want to recommend something that fits the business and its next changes. For a modest deployment with existing firewalls, that can still be a traditional VPN. Different connection conditions or management requirements make the mesh approaches worth considering. I would base the decision on whether the required connections can be operated securely, understood and restored after a failure.

Until next time,
Joe