Wireguard routing from wg1 to wg0

I have two networks configured with Wireguard. wg0 is for servers and wg1 for VPN users. When a VPN user on wg1 wants to reach the wg0 network, the packets should be router over one of the wg0 servers (the VPN gate).

wg0.conf on VPN gateway and on all servers with wg0 interface

[Interface]
Address = 10.1.0.15
ListenPort = 51820
PrivateKey = privatekey1

# node23
[Peer]
PublicKey = pubkey
AllowedIps = 10.1.0.23
Endpoint = node23.fqdn:51820

# node24
[Peer]
PublicKey = pubkey
AllowedIps = 10.1.0.24
Endpoint = node24:51820

# node25
[Peer]
PublicKey = pubkey
AllowedIps = 10.1.0.25
Endpoint = node25.fqdn:51820
...

wg1.conf on VPN gateway

[Interface]
Address = 10.100.0.1/32
ListenPort = 51810
PrivateKey = privatekey2

PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# user1    [Peer]
PublicKey = pubkey
AllowedIps =  10.100.0.2/32
...

And this is the users wg1.conf (actually wg0 because they don't have a 10.1.0.0 address)

[Interface]
Address = 10.100.0.2/32
ListenPort = 21841
PrivateKey = myprivatekey

[Peer]
PublicKey = pubkey
EndPoint = vpngate.fqdn:51810
AllowedIPs = 0.0.0.0/0

PersistentKeepalive = 25

So, on the VPN gate itself I can run curl -v http://10.1.0.23/ and I'm getting a response within the wg0 network. Ping works to. I can reach all servers within the network. The same with wg1-client and wg1-server. Also I can browse the internet via the VPN gate. But when I try to call from my wg1-client a wg0-server like curl -v http://10.1.0.23/ which should be route (I think) thru the vpn-gate and from there via wg1 -> wg0 there is no response.

What do I miss?

Solution 1:

From reading WireGuard's Cryptokey Routing explanations:

In the server configuration, each peer (a client) will be able to send packets to the network interface with a source IP matching his corresponding list of allowed IPs. For example, when a packet is received by the server from peer gN65BkIK..., after being decrypted and authenticated, if its source IP is 10.10.10.230, then it's allowed onto the interface; otherwise it's dropped.

=> An incoming address must be in the AllowedIPs to be associated to the cryptokey defined in Peers and allowed.

In the server configuration, when the network interface wants to send a packet to a peer (a client), it looks at that packet's destination IP and compares it to each peer's list of allowed IPs to see which peer to send it to. For example, if the network interface is asked to send a packet with a destination IP of 10.10.10.230, it will encrypt it using the public key of peer gN65BkIK..., and then send it to that peer's most recent Internet endpoint.

=> Likewise, an outgoing address must be in the AllowedIPs so the correct cryptokey and its Peer current remote endpoint can be selected.

When the client runs curl -v http://10.1.0.23/, outgoing packets do:

10.100.0.2  ----> ✔ 10.100.0.1 ==> 10.1.0.1  ----> ❌ 10.1.0.23
        wg0       wg1                    wg0       wg0
client                     gateway                   server

10.100.0.2 is not in server's wg0's AllowedIPs for the gateway Peer entry so the packet is dropped.

Likewise if a server attempted to reach the client (with its route correctly configured to use wg0), it wouldn't find a matching Peer for the destination address so would receive an error when sending (the error, as an error returned by a network syscall, is probably specific to WireGuard: ENOKEY (Required key not available)).

So if clients are all in 10.100.0.0/24, they must appear in each server's configuration on the Peer section for the gateway, in the AllowedIPs entry. So if the gateway's address is 10.1.0.1 (can't find this information in OP), the servers should all include something similar to:

# gateway
[Peer]
PublicKey = pubkey
AllowedIPs = 10.1.0.1,10.100.0.0/24
Endpoint = vpngate.fqdn:51820

The reverse direction won't have a problem since the client is configured to associate any IP received on wg0 to the gateway.

The gateway itself doesn't have to change any configuration.