Only able to connect to Wireguard peer after I ping the server

Question

So I have 1 computer set up as a server and all the others as peers. Here's the server config:

[Interface]
Address = 10.0.0.1/16
SaveConfig = false
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enp6s0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o enp6s0 -j MASQUERADE
ListenPort = 51820
PrivateKey = <key>

# ... more peers that work fine ...

[Peer]
PublicKey = <key>
AllowedIPs = 10.0.55.2

And here's the config of the new peer that is causing problems:

[Interface]
Address = 10.0.55.2
SaveConfig = false
ListenPort = 51820
PrivateKey = <key>

[Peer]
PublicKey = <key>
AllowedIPs = 10.0.0.0/16
Endpoint = my.endpoint.com:51820

I can only connect to this new peer AFTER I pinged the server from that new peer. Until then I only get Destination Host Unreachable messages.

I also tried using just /24 addresses, but that didn't change anything.

Does anyone know what's going wrong?

I guess I could add a ping command as a PostUp command, but that seems like a poor fix.

Answer 1

Packets are ultimately sent to the MAC address of the destination host. This requires that the MAC address of the destination host be in the ARP table of the sending host, or that the MAC address of the sending hosts Default Gateway be in the sending hosts ARP table (for non-local communication). If the sending host and destination host are on the same Layer 3 network then the sending host will broadcast for the MAC address of the destination host on the local network. If the sending host and destination host are on different Layer 3 networks then the sending host will broadcast for the MAC address of it's configured Default Gateway on the local network. When it receives a reply it will add that MAC address to it's ARP table.

Until you initiate communication with the server from the client, the client has neither the servers MAC address in it's ARP table nor the MAC address of it's Default Gateway in it's ARP table... unless the client has already communicated with a non-local host.

My guess is this is what's causing the issue. Are the client and server on the same Layer 3 network? We can't tell because you omitted the netmask of the client in your question.

Answer 2

I have testing WireGuard in a home lab and I found the same problem.

I have two routers, one is the default GW in destination network and another -behind NAT of GW- with WireGuard server. I even having the route to the WireGuard network in the default GW, - and pings to each host -as you say- on the destination network from the WireGuard client, I have needed to manually add the route to the WireGuard network, on the destination host manually.

It finally worked.

Theoretically, if your default router also acts as a WireGuard server. It should work without problems, but in my case, I should have done it like this.