Forwarding WireGuard Connections on Windows

Enabling packet forwarding on a WireGuard hub is the simplest kind of forwarding to configure. For example, if you’ve set up WireGuard on a Windows machine like the “Host C” hub in the WireGuard Hub and Spoke Configuration guide:

You can enable packet forwarding by running the following PowerShell Set-NetIPInterface command as an Administrator on Host C:

The above command enables both IPv4 and IPv6 forwarding. Alternatively, you could enable each version separately by running the following netsh commands:

Both sets of commands above are the equivalent of turning on the IP forwarding kernel parameters on a Linux machine:

To check the current forwarding state of each network interface on a Windows machine, run the following PowerShell command:

Enabling packet forwarding for a WireGuard site gateway is only a little more complicated than for a hub. You need to run the same commands on the site gateway as on the hub — but for both the WireGuard interface (wg0) and the site-facing Ethernet adapter (usually named Ethernet):

Run these commands on the WireGuard host for both sites in a Site-to-Site connection (eg both “Host α” and “Host β” in the WireGuard Site to Site Configuration guide), or on the site host of a Point-to-Site connection (eg “Host β” in the WireGuard Point to Site With a Site Gateway guide).

Note that you will still have to update the routing tables on the LAN router (or each individual computer you want to expose) at the site in order for traffic from the other computers at the site to actually be routed to the WireGuard site host. For example, in the WireGuard Point to Site With a Site Gateway guide, the WireGuard network is using the 10.0.0.0/24 address block, and the WireGuard site host (Host β) has an address of 192.168.200.2 on the LAN:

So on the LAN router at Site B, you would have to add a route like the following:

Setting up masquerading (aka Source Network Address Translation or SNAT) on a WireGuard site host for a Point-to-Site connection is only a little more complicated. You simply have to use the New-NetNat command and specify the address block of source addresses that should be masqueraded.

For example, if you’ve set up WireGuard on a Windows machine to be a site host like “Host β” in the WireGuard Point to Site Configuration guide, 10.0.0.0/24 is the address block of WireGuard addresses that the site host should masquerade to the site LAN:

To enable this, run the following PowerShell command as an Administrator on Host β:

Unlike with Linux, you do not have to separately enable packet forwarding; Windows will automatically allow forwarding from any source addresses in the specified address block (such as 10.0.0.1, the WireGuard “Point” in the Point to Site Configuration example), and will automatically rewrite the source address of those forwarded connections to use the address of whatever interface the connection is forwarded out (such as 192.168.200.2, the LAN address of Host β above).

Run the following PowerShell command to see the current list of SNAT configurations:

Note that the wg0nat name in the above example is completely arbitrary — it doesn’t have to include the WireGuard interface name. It’s relevant only for the purpose of updating or deleting existing SNAT configurations; for example, run the following command to remove the SNAT added above:

Enabling port forwarding (aka Destination Network Address Translation or DNAT) on a WireGuard host takes a few more steps. The first step is to determine the original destination address and port that will be used by incoming packets which should be forwarded, and the destination address and port to which those packets should be rewritten.

With the example from the WireGuard Point to Site With Port Forwarding guide, “Host β” should forward incoming TCP port 80 packets from its site LAN, using its LAN address of 192.168.200.2, to TCP port 80 of WireGuard “Endpoint A”, which has an IP address of 10.0.0.1 on the WireGuard network:

To set up this DNAT, first run the following netsh command as Administrator on Host β:

For IPv6 addresses, use the v6tov6 subcommand instead of v4tov4. Unlike with Linux, you do not need to separately enable packet forwarding, and you do not need to separately enable SNAT — connections that match this DNAT rule will automatically be forwarded, and have their source address translated to match the interface out of which they’ll be forwarded (10.0.0.2 in this example).

Next, add a firewall rule on Host β with the New-NetFirewallRule PowerShell command to allow the incoming connection to be accepted before it is translated:

The above firewall rule will allow connections to TCP port 80 from anywhere. You might, however, want add a -RemoteAddress option to constrain the source machines from which Host β will forward; for example, you might add the following -RemoteAddress 192.168.200.0/24 option to forward connections only from Host β’s own LAN:

The combination of the above port-proxy command and firewall rule will allow the example Host β to forward HTTP connections from its site LAN through WireGuard to Endpoint A.

To list the active port-proxies, run the following command:

To delete the port-proxy set up above, run the following command with the listen address and port to delete:

And to delete the firewall rule set up above, run the following PowerShell command with the name of the rule to delete: