WireGuard Port Forwarding From the Internet to Other Networks

When the private server is using the intermediate server as a WireGuard hub to the public server, make the same changes shown in the Policy Routing section of the WireGuard Port Forwarding From the Internet article to the private server’s WireGuard config:

Also make a similar change to the intermediate server, but with a different policy routing rule:

The policy routing rule on the hub routes all incoming packets received on the hub’s WireGuard interface using the custom routing table 123. WireGuard’s wg-quick script automatically sets up this table with routes inferred from the AllowedIPs settings in the interface’s WireGuard config. This ensures that incoming WireGuard packets on the hub will always be forwarded out the same WireGuard interface.

The policy routing rule on the spoke applies not to incoming packets — but to outgoing ones. It routes all outgoing packets with a source address that matches the spoke’s WireGuard interface address, using the spoke’s custom routing table 123. This works because all outgoing return traffic generated by the private service will use the source address of the network interface on which the connection was originally received; when the private service receives a new connection through WireGuard at its WireGuard IP address of 10.0.0.3, that’s the source address it will use for return traffic.

When the private server is not connected to the intermediate server via WireGuard, you’ll need to use similar policy routing rules, but you’ll need to select packets using a different set of criteria.

On the private server, if the intermediate server isn’t already its default gateway, run the following two commands to make it the default gateway just for the private service:

The first command sets up a custom routing table (123) with a default route to the intermediate server (172.31.0.1). The second command adds a policy routing rule to route all outgoing packets sent from the private service (listening on TCP port 8080) using the custom routing table.

On the intermediate server, make similar changes to its WireGuard configuration as for hub-and-spoke, but with a different policy routing rule:

This policy rule will route all packets the intermediate server receives from the private server (172.31.0.3) using the custom routing table.

There are several different types of “marks” that can be applied to various aspects of a network connection under the Linux networking stack. These are the two relevant to this technique:

In order to keep track of connections, you need to use the connection mark; but in order to use the connection mark with routing, you need to copy the connection mark to the packet mark on each individual packet you want to affect.

Also, there is only one single packet mark field available on each packet, and one connection mark field available for each connection. Therefore, if you ever need to use the packet or connection mark for more than one purpose (for example, for routing one group of packets and rate limiting another group), you’ll need to choose different mark values for those different purposes (eg a mark value of 1 for one purpose, a mark value of 2 for another, and so on) — and if you need to maintain different mark values on the same packet or connection at the same time, you will need to resort to bitmasking the mark value when setting and checking the mark.

When the techniques discussed earlier won’t work, and the intermediate server is either a Docker host running the private server as a container, or is the LAN router for the private server, you’ll need to use connection marking in conjunction with policy routing on the intermediate server.

There are six steps to this technique:

When using iptables, the WireGuard config file for the intermediate server would look like this:

If you’re using nftables instead of iptables, rather than adding the above iptables rules to the intermediate server’s WireGuard config file, add the following table to its nftables config file (or if you already have a similar “mangle” prerouting chain, just copy these two rules to your existing chain):

You won’t need to adjust the private server at all in this scenario, as it will already use the intermediate server as its default gateway.

When the earlier techniques won’t work, and the intermediate server is on the private server’s LAN but is not the private server’s default gateway, you’ll need to use connection marking in conjunction with policy routing on the private server. The steps you need to follow are similar to the above Connmark on the Intermediate Server section, but the details are a bit different as the private server will need to return traffic through its LAN interface to the intermediate server, instead of through a WireGuard interface.

We’ll also perform these steps in a little different order than the previous section:

First, add a firewall rule to mark new connections incoming from the intermediate server, matching them by the intermediate server’s MAC address (eg 12:34:56:78:90:ab) on the LAN it shares with the private server:

Next, add a second firewall rule to mark outgoing return packets that have the connection mark from the first rule:

Thirdly, add a custom routing table (123) with a default route to the intermediate server (172.31.0.1):

Then add a policy routing rule to route marked packets using the custom table (123):

Finally, if you’re using strict reverse path forwarding Source Address Validation on the private server, you’ll need to loosen it:

To use nftables instead of iptables for the first two steps, add the following table to the private server’s nftables config file (or if you already have similar “mangle” prerouting and output chains, just copy these rules to your existing chains):

On the intermediate server, set up Policy Routing the same way as in the When Not Hub-and-Spoke sub-section (no connection marking on the intermediate server is necessary unless the private server also uses it as a route to other internal networks):

With the relatively simple hub-and-spoke WireGuard network shown as an example in this article, you wouldn’t ever actually need to use connection marking. But for the sake of illustrating this technique, let’s imagine a more complicated scenario with two public servers (call them “Public Server 1” and “Public Server 2”) that forward traffic from the Internet through WireGuard to the same destination port on the same private server.

In this more complicated scenario, the intermediate server would use a separate WireGuard interface to connect to each public server (wg1 and wg2, in addition to using wg0 for its connection to the private server). The intermediate server would need to use connection marking to keep track of which interface (wg1 or wg2) to route the return traffic from the private server.

In this case, the intermediate server’s WireGuard config for its connection to the private server (wg0) might look like the following:

And the intermediate server’s WireGuard config for its connection to the first public server (wg1) might look like this:

And the intermediate server’s WireGuard config for its connection to the second public server (wg2) like this:

This configuration ensures that replies to traffic originally forwarded in from Public Server 1 will return back out through Public Server 1, replies to traffic originally forwarded in from Public Server 2 will return back out through Public Server 2, and any Internet traffic originating on the intermediate server itself (such as for its own software updates or DNS queries) will be sent out through the intermediate server’s default gateway.

The connection-marking examples above are not compatible with strict RPF (Reverse Path Forwarding) SAV (Source Address Validation). This kind of SAV (aka “reverse path filtering”) automatically drops incoming packets if they do not come in the same interface the routing subsystem calculates that it will send return packets back out (aka “martian packets”) — and the above examples do not allow the routing subsystem to make accurate reverse path calculations (as the above examples don’t mark packets on the forward path, only the return path).

It’s possible to use connection marking with strict RPF; however, it’s slightly more complicated, and won’t provide any benefit unless you also add additional policy routing rules (or additional routes to your custom routing tables) for address blocks that should never be routed through WireGuard. Therefore, when using this technique, if the Linux kernel’s own built-in RPF setting (the net.ipv4.conf.all.rp_filter network kernel parameter) is configured to “strict” (1), you should change it to “loose” (2) for the interfaces with which you’re using connection marking (as shown in the above examples).

If you’re applying SAV via firewall, you should customize your firewall rules to account for how you’re using WireGuard. For example, you might be using an nftables rule like the following to drop any packets that fail strict RPF:

If so, you might want to simply exempt the WireGuard interface from the strict RPF check:

Or you might want to first validate that only packets with a Internet-routable source address are coming in the WireGuard interface (in addition to packets received directly from other WireGuard peers):