Primary WireGuard Topologies
These are the four primary topologies you’d consider when deciding how to connect two endpoints over a WireGuard network:
They all work for all the usual reasons why you would connect two endpoints, like to allow the endpoints to communicate over SSH, or for one endpoint to connect to an HTTP server on the other, or for one endpoint to access the shared folders of another, etc.
Unlike some VPN technologies, WireGuard doesn’t have strict “client” or “server” roles. All WireGuard peers are equally capable of performing what one might think of as a “client” or a “server” role.
But to keep things simple for this article, I’m going to consistently use examples with an “Endpoint A”, representing a “client” endpoint (like an end user’s tablet), connecting through a WireGuard tunnel to an “Endpoint B”, representing a “server” endpoint (like a server running some web application the end user wants to use). And I’ll use port 51821 to represent the WireGuard peer running on the “client” side of the tunnel, and port 51822 to represent the WireGuard peer on the “server” side (and port 51823 in the case where there’s an intermediary WireGuard peer between the two).
Point to Point
The simplest topology is just Point to Point — one endpoint running WireGuard connected directly to another endpoint running WireGuard. It’s also the only topology that produces E2E (End-to-End) encryption — all other topologies involve WireGuard packets being decrypted by an intermediary at some point between endpoints.
In order to make Point to Point work, the WireGuard port on one of the endpoints must be open to new connections through all firewalls between the two endpoints.
In the simplest Point to Point scenario, both endpoints would be on the same LAN (Local Area Network), with any firewalls between the two endpoints configured to allow either endpoint to connect to the other’s WireGuard port. In this case, either endpoint can initiate a connection to the other at any time.
In a more complicated, but common, scenario, both endpoints would be behind firewalls and NAT (Network Address Translation), with the Internet in between. Here the firewalls in front of Endpoint A allow only established connections through to Endpoint A. The firewalls in front of Endpoint B allow new connections through to port 51822, and the NAT in front of Endpoint B forwards port 51822 to Endpoint B.
In this scenario, Endpoint A can initiate a new connection at any time to Endpoint B. But because Endpoint A is behind a firewall that allows only already-established connections, if you want to enable Endpoint B to initiate connections to Endpoint A, you must configure the PersistentKeepalive setting on Endpoint A (a value of 25, meaning send a keepalive packet every 25 seconds, will work well for most cases).
A Mesh topology effectively is just a bunch of individual Point to Point connections among a group of endpoints.
See the WireGuard Point to Point Configuration article for an example of how to set up endpoints with this configuration.
Hub and Spoke
The next basic topology is Hub and Spoke (also known as the Star topology), where two endpoints running WireGuard are connected through a third host, also running WireGuard. This third host operates as a router among the WireGuard endpoints connected to it, forwarding the packets it receives though a WireGuard tunnel from one endpoint on to a second endpoint through a different WireGuard tunnel.
You’d often connect more than just two endpoints in this way — this topology is a good way to enable remote access management among a diverse set of remote endpoints; or to create a virtual LAN out of a number of disparate remote hosts, with routing rules, access control, and traffic inspection all centralized in one place (the hub).
Hub and Spoke can also be a useful tool to connect two endpoints that both lie behind firewalls which do not allow new incoming connections, or behind NAT which does not allow port forwarding (where you’d use the hub simply as a “bounce server”).
In the simplest Hub and Spoke scenario, all hosts are on the same local network, with any firewalls between the two “spoke” endpoints (Endpoint A and Endpoint B) and the “hub” host (Host C) configured to allow the spokes to connect to the hub on the hub’s WireGuard port (51823), and similarly allowing the hub to connect to the spokes on each spoke’s WireGuard port (51821 for Endpoint A and 51822 for Endpoint B).
Once the WireGuard tunnel between Endpoint A and Host C is up, and the separate WireGuard tunnel between Endpoint B and Host C is up, Host C can route packets sent from Endpoint A to Endpoint B, and vice versa.
In a more complicated scenario, both the hub and spokes are behind firewalls and NAT, with the Internet in between. The firewalls in front of Endpoint A and Endpoint B allow only established connections through to Endpoint A and Endpoint B. The firewalls in front of Host C allow new connections through to port 51823, and the NAT in front of Host C forwards port 51823 to Host C.
In this scenario, while Endpoint A and Endpoint B can each independently initiate new connections with Host C, because of the firewall rules for Endpoint A and B, Host C can’t initiate new connections with either. Therefore, in order to enable Endpoint A to initiate connections through WireGuard to Endpoint B, you must configure the PersistentKeepalive setting on Endpoint B. And if you want to allow Endpoint B to also be able to initiate connections through WireGuard to Endpoint A, you must configure the PersistentKeepalive setting on Endpoint A.
See the WireGuard Hub and Spoke Configuration article for an example of how to set up three WireGuard peers with this configuration.
Point to Site
With a Point to Site topology, a remote endpoint is connected via WireGuard to a different host in another network, where that host can route packets from the remote endpoint to various other local endpoints within its network. Point to Site is kind of like Hub and Spoke, except that some of the spokes (the ones on the same LAN as the hub) don’t use a WireGuard tunnel.
Point to Site is nice for a number of use-cases where you want to allow remote access from a discrete endpoint to a variety of servers on the same LAN, without setting up and managing WireGuard separately on each one of those servers. You might have cases like:
- a remote PC connecting to various servers on an office LAN (aka Road Warrior)
- a workstation in an office LAN connecting to several servers in a cloud network (aka Point to Cloud)
- a cloud VM connecting in to various servers on your office LAN
- a cloud server connecting to other servers in another cloud network
In the simplest Point to Site scenario, you have one endpoint with WireGuard running on it (the “remote endpoint”, Endpoint A) connected directly to another host running WireGuard (Host β); and that other host can serve as a router to other endpoints within the local site (Site B), including Endpoint B (the “local” endpoint).
Any firewalls between Endpoint A and Site B in this scenario would be configured to allow Endpoint A to connect to Host β, and vice versa. This enables the remote endpoint (Endpoint A) to initiate a connection to any local endpoint, and any local endpoint (like Endpoint B) to initiate a connection to the remote endpoint.
In a more complicated scenario (and one that you’re more likely to see), both the remote endpoint (Endpoint A) and the local site (Site B) are behind firewalls and NAT, with the Internet in between. The firewalls in front of Endpoint A allow only established connections through to Endpoint A. The firewall in front of Site B allows new connections through to port 51822, where a host running WireGuard (Host β) accepts WireGuard connections on port 51822, and routes authorized traffic from its WireGuard tunnels to endpoints within the site (like Endpoint B).
The traffic within the local site (Site B) is not tunneled through WireGuard, and so is subject to any firewall or other routing restrictions to which other local traffic is subject. In this scenario, an HTTP request between Endpoint A and Endpoint B will travel through the WireGuard tunnel from Endpoint A to Site B, and then will be routed locally like any other local traffic from the WireGuard tunnel to Endpoint B. So in order for HTTP traffic from Endpoint A to make it all the way through to port 80 on Endpoint B, any firewall between Host β and Endpoint B needs to allow port 80 from Host β to Endpoint B.
Like with the Point to Point scenario, Endpoint A can initiate a new connection at any time to Endpoint B. But because Endpoint A is behind a firewall that allows only already established connections, if you wanted to enable Endpoint B to initiate connections to Endpoint A, you would have to configure the PersistentKeepalive setting on Endpoint A.
See the WireGuard Point to Site Configuration article for an example of how to set up WireGuard with this configuration; and see the WireGuard Point to Site Routing article for a comparison of the different ways to set up routing with a Point to Site topology.
Site to Site
A Site to Site topology is like Point to Site, except there’s a full site on both ends of the WireGuard tunnel. This is an easy way to build a virtual LAN to LAN connection (or Cloud to Cloud, or LAN to Cloud, etc).
Like with Point to Site, on one end you have a host running WireGuard, and that host can route to various endpoints within its own site. And on the other end of the connection, you also have a different host running WireGuard in a different site, and this host can also route to endpoints within its own site.
In its simplest form below, you have two adjacent subnets, Site A and Site B, connected by a WireGuard tunnel. Traffic in Site A (like from Endpoint A) destined for an endpoint in Site B (like Endpoint B) is routed to the WireGuard host (Host α) in Site A, through the WireGuard tunnel to Site B, and out from the WireGuard host (Host β) in Site B to the endpoint in Site B.
Any firewalls between Site A and Site B in this scenario should be configured to allow Site A to connect to Site B’s WireGuard port, and vice versa. This enables any endpoint in Site A to initiate a connection to any endpoint in Site B, and vice versa.
In a more complicated scenario, both sites would be behind firewalls and NAT, with the Internet in between. The firewall in front of Site A allows new connections through to port 51821, where Host α accepts WireGuard connections on port 51821, and routes authorized traffic from its WireGuard tunnel out to endpoints within the site. Similarly, the firewall in front of Site B allows new connections through to port 51822, where Host β accepts WireGuard traffic to it, and routes authorized traffic from its WireGuard tunnel out to endpoints within Site B.
In this scenario, the WireGuard hosts for Site A and Site B both live in a DMZ (Demilitarized Zone) of their respective sites, where they’re publicly addressable from the Internet, but can also route to the private address space used by their own site (as well as the private address space used by the WireGuard networks to which they belong).
Traffic from Endpoint A to Endpoint B in this scenario is routed first to Host α, through the WireGuard tunnel between Site A and Site B, out from Host β, and finally on to Endpoint B. The firewall between Endpoint A and Host α allows traffic out from Endpoint A (and traffic from established connections back in); and the firewall between Host β to Endpoint B allows HTTP (port 80) traffic incoming to Endpoint B (and corresponding traffic back out).
The firewalls between Host α and Host β allow either WireGuard host to initiate a connection to the other — and so, generally, by using the WireGuard tunnel, any endpoint in Site A could initiate a connection to any endpoint in Site B, and vice versa. However, the firewall between Endpoint A and Host α allows only established connections into Endpoint A, protecting it from new connections from Site B.
If we wanted to allow endpoints in Site B to be able to initiate new connections to Endpoint A, there’s nothing WireGuard-specific we’d do to enable that — we’d just change our firewall rules for the firewall between Endpoint A and Host α to allow new connections in (like we’ve done for Endpoint B, which allows new HTTP connections on port 80 from Host β).
See the WireGuard Site to Site Configuration article for an example of how to set up WireGuard hosts with this configuration.
Other Topologies
Pretty much all other topologies you’d use with WireGuard you can build by composing these four basic patterns. For example, for a WireGuard network consisting of several discrete remote endpoints (for your road warriors) connected to a LAN (at your office HQ), you might combine Hub and Spoke with Point to Site, where the remote endpoints would be the spokes of Hub and Spoke, and the hub of Hub and Spoke would also be the site’s WireGuard host from Point to Site.
As another example, for a WireGuard network joining three office LANs plus two cloud sites, you might use the Site to Site topology between each individual site, creating a separate WireGuard tunnel from the WireGuard host in each site to each of the other four sites. Or you might decide to use a combination Hub and Spoke with Site to Site, allowing you to centralize your site-to-site routing and access control in one place, and connect the WireGuard host at each site only to a single hub host, to which all the other sites also connect.