WireGuard Point to Site Routing

The most commonly-used strategy is packet masquerading, also known as SNAT (Source Network Address Translation). With this strategy, Host β above would forward packets from Endpoint A to Endpoint B after re-writing the source address of those packets to use its own IP address, instead of Endpoint A’s. From the perspective of Endpoint B in the local site, the remote packets from Endpoint A would appear to be coming directly from Host β (with an IP address of 192.168.200.2), not Endpoint A (with an IP address of 10.0.0.1).

Packet masquerading is the most commonly used strategy for point to site because it’s easy to set up, and usually matches the “direction” of access that the VPN is meant to enable. It doesn’t require any routing changes on the “Site” side — it just requires a few simple firewall rules on the masquerading host (Host β in the above example). And it allows WireGuard endpoints on the “Point” side to initiate connections to non-WireGuard endpoints on the “Site” side:

To set up a point-to-site WireGuard network with packet masquerading, follow the instructions in the Point to Site With Masquerading Configuration guide.

The two drawbacks to masquerading are:

Because all the hosts in Site B will see packets coming from Endpoint A as if they were instead coming from Host β, they can’t tell the difference between packets actually originating from Host β and those originating from Endpoint A (or from any other WireGuard endpoint connected to Host β). It’s Host β’s IP address that will show up in their logs; and if they use IP addresses to make authentication or authorization decisions, it’s Host β’s IP address that they’ll use, not Endpoint A’s.

Also, hosts in Site B (other than Host β itself) won’t be able to initiate any connections to Endpoint A. If you do need hosts at the local site to be able to initiate connections to a remote endpoint (like because the endpoint is running a web server or database that the hosts in the local site need to access), you can combine masquerading with Port Forwarding — or, alternatively, you can use a Site Gateway instead of packet masquerading.

Post forwarding, also known as DNAT (Destination Network Address Translation), is used with WireGuard when you have a service, like a web app or database, running on a remote endpoint that you want to expose to a local site. With this strategy, Host β above would forward packets sent to it from Endpoint B over its WireGuard connection to Endpoint A — after first re-writing the destination address of those packets to use Endpoint A’s address instead of its own. From the perspective of Endpoint B in the local site, it’s connecting to Host β directly (using Host β’s IP address of 192.168.200.2), and not to Endpoint A at all (it won’t see Endpoint A’s IP address of 10.0.0.1).

Port forwarding is used when the “direction” of access that the VPN is meant to enable is outgoing (you might say “Site to Point” instead of “Point to Site”):

To set up a point-to-site WireGuard network with port forwarding, follow the instructions in the Point to Site With Port Forwarding Configuration guide.

The drawback to port forwarding is that WireGuard endpoints on the “Point” side cannot successfully initiate connections to the “Site” side. Unlike with Masquerading, Host β won’t re-write the source address of any that packets Endpoint A sends to Endpoint B (except for the responses to packets to which it recently applied port forwarding) — therefore, those packets will contain Endpoint A’s original source address of 10.0.0.1, and Endpoint B won’t know that it has to send packets back through Host β to reply to connections from 10.0.0.1.

You can combine port forwarding with masquerading; but usually if you need bi-directional connection initiation between a remote WireGuard endpoint and non-WireGuard endpoints at a local site, the better choice is to use a WireGuard host at the local site as a Site Gateway.

A WireGuard site gateway is used to avoid NAT (Network Address Translation) entirely. With this strategy, the hosts in Site B above (or at least Site B’s default gateway) have be configured to know that all packets destined for Endpoint A need to be forwarded through Host β — therefore, the firewall on Host β doesn’t need to do any packet re-writing to make sure that packets are routed correctly. When Endpoint B wants to send a packet to Endpoint A, it just uses Endpoint A’s own WireGuard IP address (10.0.0.1) as the destination; and when Endpoint B receives a packet from Endpoint A, it will see Endpoint A’s address (10.0.0.1) as the packet’s source.

If you are able to configure the routing tables used by Site B easily, a site gateway is usually the best choice to enable site-to-point WireGuard — especially if you need to initiate connections bi-directionally (both “Point to Site” and “Site to Point”):

To set up a point-to-site WireGuard network with a site gateway, follow the instructions in the Point to Site With a Site Gateway Configuration guide.

The drawback to using a site gateway is that you need to be able to configure the routing tables used by Site B — either on the individual hosts in Site B manually, or via DHCP, or on the site’s default gateway itself (at small sites, this is often the Internet router).