WireGuard Transparent Tunnel

The first thing we need to do on Endpoint A is add Endpoint B’s public IP address to the AllowedIPs setting in Endpoint A’s WireGuard configuration:

This would normally break Endpoint A’s WireGuard connection with Endpoint B, as the address in its Endpoint setting is now also included in its AllowedIPs setting (which would normally cause Endpoint A to try to route encrypted WireGuard traffic to Endpoint B back through the WireGuard interface again and again in an infinite loop).

To avoid this breakage, we need to use a custom routing table for the WireGuard interface. We can do this by adding the Table setting to the [Interface] section of Endpoint A’s WireGuard config, setting it to any unused routing table number (such as 123):

When we start up the interface, routes for all addresses included in the interface’s AllowedIPs settings will be added to this custom table (instead of to the main routing table).

By default, however, Endpoint A won’t route any traffic using this custom table.

So next we need to add some policy routing rules that tell Endpoint A when to use this custom routing table. We can add these rules via PreUp or PostUp scripts in Endpoint A’s WireGuard configuration, and tear them down via corresponding PostDown or PreDown scripts.

We need to make sure encrypted WireGuard traffic sent to Endpoint B’s WireGuard listen port is routed out Endpoint A’s physical Ethernet interface as normal, but all other traffic sent to Endpoint B is routed out Endpoint A’s virtual WireGuard interface first (where it will be encrypted and tunneled to Endpoint B’s WireGuard listen port). We can accomplish this with two rules.

The first rule routes traffic to the listen port (51822) of Endpoint B (203.0.113.2) using Endpoint A’s normal (main) routing table:

And the second rule routes all other traffic to Endpoint B using the custom routing table (123) we configured via the Table setting above:

Make sure to give the first rule a smaller priority number than the second (455 vs 456 in this example), as rules with smaller priority numbers are evaluated first.

At this point, we’ve done enough on Endpoint A to ensure that any traffic to Endpoint B’s public address of 203.0.113.2 will use be routed through WireGuard. However, we’ve broken Endpoint A’s ability to route traffic to Endpoint B’s WireGuard address of 10.0.0.2. We can fix this with any one of three options:

After making all four changes, using the first option (Expand Address Subnet Mask) for the fourth change, the WireGuard configuration for Endpoint A will look like this:

Now start the interface up (eg sudo wg-quick up wg0). If you haven’t already set up the WireGuard configuration on Endpoint B, follow the directions in the Point-to-Point WireGuard Configuration article to do so now.

Once WireGuard is up and running on both endpoints, we should be able to access Endpoint B using its IP address and public DNS name from Endpoint A, transparently through the WireGuard tunnel:

We can verify that requests from Endpoint A are coming through the WireGuard tunnel by checking the webserver’s access logs on Endpoint B. Requests for https://app.example.com from Endpoint A should now show up with Endpoint A’s WireGuard IP address (10.0.0.1) instead of its public IP address (198.51.100.1):

On Endpoint B, shut down its WireGuard interface, and make the same changes we made to its configuration that we made on Endpoint A:

Since Endpoint A’s public IP address is 198.51.100.1 and its WireGuard listen port is 51821, here we’ve used 198.51.100.1 in Endpoint B’s configuration where we used 203.0.113.2 in Endpoint A’s configuration, and 51821 where we used 51822.

To set up a SNAT rule for Endpoint A’s traffic on Endpoint A’s own firewall, the rule must be added to the POSTROUTING chain of the nat table. We could do this with iptables via a PreUp script in Endpoint A’s WireGuard config file like the following:

Alternatively, to set up a SNAT rule for Endpoint A’s traffic on Endpoint B’s firewall, the rule must be added to the INPUT chain of the nat table. We could do this with iptables via a PreUp script in Endpoint B’s WireGuard config file like the following:

After making those changes for Endpoint B, and starting its WireGuard interface back up (eg sudo wg-quick up wg0), we should still be able to access Endpoint B using its IP address and public DNS name from Endpoint A, transparently through the WireGuard tunnel:

But now if we check the webserver’s access logs on Endpoint B, we should see requests sent through the WireGuard tunnel recorded with Endpoint A’s public IP address (198.51.100.1) instead of its WireGuard IP address (10.0.0.1):

However, now that all traffic sent through the WireGuard tunnel is transparently using the public IP addresses of Endpoint A and Endpoint B, how do we tell the difference between traffic sent through the tunnel and traffic sent over the public Internet? We can tell the difference by checking the network interface used by the traffic.

If we use tcpdump to monitor the wg0 interface of Endpoint A or Endpoint B, and run our cURL command again, we’ll see the request come through the WireGuard tunnel: