Wireguard – How to Forward/Route Packets via Wireguard Overlay Network

iptableslinuxroutingwireguard

My question is related to basics in network routing and iptables, and is probably due to my lack of understanding on how I should set this up.

I have established an overlay network between hosts using wireguard, where one is behind a Router/NAT. In so far the overlay network works well, and each host can talk to the others.

Now, I would like to make Host A a gateway to the private network, but I am miserably failing to do so.

Can you maybe help me unravel the mystery that is iptables forwarding?

3 Networks

The overlay network of the VPN is 169.254.0.0/24 and the private network behind the router is a 192.168.0.0/24.

The internet 🐈
The overlay network (169.254.0.0/24, running on Wireguard)
The private network (192.168.0.0/24)

4 Hosts

VPN Server

wg0: 169.254.0.1
Client

wg0: 169.254.0.2
Host A

wg0: 169.254.0.3
eth0: 192.168.0.33
Host B

eth0: 192.168.0.53

In order to illustrate the real network, here is this picture:

And here is the overlay network:

At which, my Client is failing to send packets to Host B via Host A.

Best Answer

Here is a working configuration. Phew, I actually got it myself, but it took me a while to get things right.

Client

I had to make sure that the peer (VPN Server) is allowed to use the 192.168.178.0/24 range.

[Interface]
Address = 169.254.0.2/32
PrivateKey = ...
ListenPort = 51280

[Peer]
PublicKey = ...
AllowedIPs = 169.254.0.1/32, 192.168.178.0/24
Endpoint = ...:51280

VPN Server

I just had to forward packets from the tun0 interface and MASQUERADE them. Furthermore, I also added the 192.168.178.0/24 network to the AllowedIPs of Host A.

$ iptables -A FORWARD -i tun0 -j ACCEPT
$ iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Wireguard configuration:

[Interface]
Address = 169.254.0.1/32
PrivateKey = ...
ListenPort = 51280

[Peer]
Endpoint = ...:51280
PublicKey = ...
AllowedIps = 169.254.0.2/32

[Peer]
Endpoint = ...:51280
PublicKey = ...
AllowedIps = 169.254.0.3/32, 192.168.178.0/24

Host A

There I needed to accept forwarding pakets on both interfaces. And I would masquerade pakets on eth0.

$ iptables -A FORWARD -i tun0 -j ACCEPT
$ iptables -A FORWARD -i eth0 -j ACCEPT
$ iptables -A POSTROUTING -o eth0 -j MASQUERADE

Wireguard wise, the configuration is nothing special. It is simply connected to the VPN server.

[Interface]
Address = 169.254.0.3/32
PrivateKey = ...
ListenPort = 51280

[Peer]
Endpoint = ...:51280
PublicKey = ...
AllowedIps = 169.254.0.1/32
PersistentKeepalive = 25

However, there was one major pitfall when working with Host A (which is behind a Router/NAT). The VPN server must know the endpoint (public ip + port) of Host A in order to send pakets to it. The Router would loose state after a while, and thus the VPN Server would no longer be able to connect to Host A.

I fixed this, by adding the PersistentKeepalive setting to the [Peer] section of the VPN server on Host A. (Thanks to @A.B from comments to point this out.)

I wonder how to solve that if both are behind a Router/NAT. Damn, that is complicated.

Related Solutions

Wireguard – Site-to-Site Configuration with Mobile Office

Unless you have some additional firewall rules set up on the Lan1 gateway host, traffic from your "road warrior" cell phone will be forwarded from your Lan1 gateway to your Lan2 gateway using the phone's original WireGuard source address of 10.100.1.2. So you need to add the phone's address to the AllowedIPs setting in the WireGuard configuration for the Lan2 gateway host:

AllowedIPs = 10.100.1.1/32, 10.100.1.2/32, 10.240.0.0/24

The Lan2 gateway will drop any packets it receives from its WireGuard connection with the Lan1 gateway when the packet's source address is not included in this AllowedIPs setting.

Wireguard VPN – Routing Only the Private Network

Set AllowedIPs to the IP addresses you want to route to/through the peer.

In a normal hub-and-spoke configuration, on your hub (S), you'd configure AllowedIPs for each peer like you have, routing packets to each peer only if they use the peer's WireGuard IP address as their destination address; and on your spokes (A, B, and X), you'd configure AllowedIPs to the CIDR of your WireGuard network (172.9.9.0/24), routing packets to the hub only if they use another peer's WireGuard IP addresses as their destination address.

So with a normal configuration, you'd access A from B or X with A's WireGuard IP address of 172.9.9.100, B from A or X with 172.9.9.101, and X from A or B with 172.9.9.10.

But if you also want to be able to access each spoke via the IP address bound to the spoke's physical NIC (eg eth0), you'd need to adjust the AllowedIPs on both the hub and the spokes to include those IP addresses.

For example, if A's eth0 address is 198.51.100.65, B's is 192.168.0.66, and X's is 192.168.0.88, you'd adjust the peers in the hub's WireGuard config to this:

## S wg0.conf
...

[Peer]
# A
PublicKey = A-public-key
AllowedIPs = 172.9.9.100/32
AllowedIPs = 198.51.100.65/32

[Peer]
# B
PublicKey = B-public-key
AllowedIPs = 172.9.9.101/32
AllowedIPs = 192.168.0.66/32

[Peer]
# X
PublicKey = X-public-key
AllowedIPs = 172.9.9.10/32
AllowedIPs = 192.168.0.88/32

And set AllowedIPs in each of the spoke's config to this:

AllowedIPs = 172.9.9.0/24
AllowedIPs = 198.51.100.65/32
AllowedIPs = 192.168.0.66/32
AllowedIPs = 192.168.0.88/32

(Note you can also specify all the blocks on one line like AllowedIPs = 172.9.9.0/24, 198.51.100.65/32, 192.168.0.66/32, 192.168.0.88/32 if you prefer.)

With your current configuration, where you have AllowedIPs = 0.0.0.0/0 on X, when you run curl 198.51.100.65 from X, what's happening is that X is routing the packets destined for A (and everything else) through its WireGuard tunnel to S, and then S is routing those packets unencrypted over the Internet to A (masqueraded with S's own public IP address); in response, A sends unencrypted packets over the Internet to S, which S routes through its WireGuard tunnel to X.

If you want to make sure S doesn't ever route packets tunneled through your WireGuard network out to the Internet, you can adjust your iptables rules to prevent this; something like the following would probably do the trick:

PostUp = iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT; iptables -A FORWARD -i wg0 -o eth0 -j DROP; iptables -A FORWARD -i eth0 -o wg0 -j DROP