When to Use WireGuard

The first use-case is connecting internal networks between remote sites. WireGuard makes it easy (using a site-to-site configuration) to connect two or more private networks over the Internet, just as if you had a dedicated link between them. For example, say you work for a primary school system, and you want to link all the office networks in that school system together, so that any school administrator can access the same internal office, file sharing, or class management software, no matter where she is physically located.

You can install WireGuard on a server at each of the office locations, and configure it to allow secure access among each office network. That way any internal servers (like Microsoft Exchange, SharePoint, etc) you have located in one office can be accessed from any other office — and nobody not on one of your office networks can access them.

The server on which you install WireGuard at each office can be the office’s Internet router, or it can be a server on which you host other applications (or it can be a dedicated machine — an old Raspberry Pi will be sufficient in most cases).

While the upside of a site-to-site connection like this is that it allows anyone in one office to access other servers at any other office, that’s also the downside. If an intruder is able to gain a foothold on one computer at any site (like, for example, one of your office admins is tricked into opening a malicious email attachment on an office computer), that attacker will be able to pivot and start probing the other computers at all connected sites.

For a concrete example of site-to-site access, see our Securing Operational Technology With WireGuard article.

Another use-case is to allow individuals around the world (or just around town) remote access to an internal network (using a WireGuard point-to-site configuration). For example, if you operate a manufacturing plant, you could set up a WireGuard server on the same internal network that you run some of your manufacturing equipment on, to allow the vendor of that equipment remote access to troubleshoot or update the equipment’s software without having to physically send someone out to your plant.

A lot of enterprises use the same approach for software-only applications. If your business has a number of internal applications hosted on some cloud network (or other off-site server farm), you might set up a WireGuard server on that off-site network to allow individual IT operators access to the servers on that network to update or troubleshoot them.

The benefit to using WireGuard this way is that it allows only specific individuals with a specific business need to access specific networks. For example, you can allow third-party vendors to access just the network on which their equipment is running, without giving them access to all your other internal networks. Or you can limit the access of your IT operators who just do application support to just access the networks which host the applications they support, instead of all your internal networks.

Another benefit is that you can revoke access from an individual to a network once she no longer needs it — for example, to revoke access when an employee leaves the company or moves to a different department. You can also selectively enable or disable access on a case-by-case basis, like to turn on access to a third-party vendor when they need to service a piece of equipment, and then turn it off again when they’re done.

For more on why WireGuard is a great way to enable remote access, see our SSH Jumphost vs WireGuard Jumphost article.

The main limitation with the above approach is that it does nothing to limit lateral movement within an internal network if a malicious actor (like a ransomware worm) gains access to any computer within it. That’s where this next use-case comes in: With WireGuard, you can establish Zero-Trust Network Access (ZTNA) among any grouping of local and remote computers to prevent unauthorized access to any of them.

In contrast with the other approaches, which allow access to a whole group of computers at the same time, with this use-case, you grant each user access only to the particular computers (or particular services running on a particular computer) that she needs to access. Also in contrast with the other scenarios, each computer must have WireGuard installed on it individually (with a point-to-point configuration), and be configured to disallow all inbound connections to it except through WireGuard.

For example, in the sales department of a company, each individual salesperson might have WireGuard installed on her laptop, and use that WireGuard connection to access the company email server (with WireGuard installed on it), her department’s file share (with WireGuard installed on it), and the internal customer-relationship-management (CRM) and invoicing applications (with WireGuard installed on them, too).

Wherever a salesperson uses her laptop — whether it’s from her office at work, from home, from a coffee shop across town, while presenting at a prospect’s site, or while traveling across the country — she’ll be able to connect to those other systems with the same level of security and availability as if she were sitting right beside them.

Although it can be more complicated to set up and administer, this is the most secure way to enable remote access among computers on any network. It ensures that only authorized individuals have remote access to each computer, and that access can be revoked to a specific computer when an individual no longer needs it. WireGuard access logs can also be used to audit in detail which users accessed which computers when and from where. And crucially, it limits the ability of an attacker who gains a foothold on one computer system from pivoting to attack the other systems on the same network.

For a guide to getting started with ZTNA, see our Zero Trust Architecture With WireGuard article.