Wireguard Site-to-Site VPN with only 1 public IP

Hello.

I'm trying to set up site-to-site VPN using Wireguard. The overall setup looks like this:

The client peer (on the left) doesn't have a public IP so it initiates the connection to the server peer (on the right) which does have a public IP. Connection gets established just fine and the client is able to see/ping devices in the 192.168.1/24 network on the server side (note: it happens despite the client's Allowed IPs list being empty for its server peer).

But the reverse isn't true: the server doesn't see the client's network (192.168.220.0/24) even though the server has its peer (the client) configured with the checkbox Route Allowed IPs checked and AllowedIPs list seemingly has all the needed entries.

What am I doing wrong? Help/suggestions are greatly appreciated.

Is the same true for the "client" peer's side? It needs to allow and route the "server" peer's local subnet as well.

1 Like

You mean that the Peer section in the client's configuration should list the server's WG network and local network (192.168.1.1/24) in the AllowedIPs ? Like:

[Peer]
Endpoint: <>
AllowedIPs: 10.0.1.1/24, 192.168.1.1/24

?

Yes. Otherwise the "client" router has no way to know to send requests and replies to the "server"'s subnet through the WireGuard tunnel. Site-to-site peer configurations need to mirror each other.

Edit: I might have "server" and "client" sides mixed up. But you know what I mean.

Got it! Just tried it and it worked, thanks a lot for your help!

I'll probably go and re-read about how WG routing works :slight_smile:

The somewhat weird thing that threw me off is that previously, even though the client's Peer/AllowedIPs section was empty, it didn't block the client from seeing the server's local network.. it was the server that was 'blind' despite it's Peer/AllowedIPs section was listing all the client's local network..

1 Like

Someone more knowledgeable than me would have to explain why that works. But that reflects my experience with WireGuard. It is actually quite forgiving when it comes to undefined details, applying some logic to them, and they seemingly "work anyway" ... until they don't. (My favorite being WireGuard interfaces without their own address.) WireGuard and its administrator's sanity benefit greatly from well-defined configurations.

1 Like

Yeah.. It feels like the AllowedIPs section has two responsibilities (which is imo often the source of confusion) - routing (for outbound traffic) and ACL (for inbound traffic).

Imo it'd be an arguably better API if instead of one AllowedIPs there were two separate sections. A-la OutboundDestinations and AllowedInbound. Of course, I may be wrong here as my knowledge of WG and the underlying design decisions is very limited.

This would throw me off too, because this scenario shouldn't have worked. With an empty AllowedIPs setting, the client Wireguard interface would not have any idea what to do for packets destined for the 192.168.1.0/24, so those would simply be ignored and Wireguard sends nothing. So the clients should not have seen the server network at all.

My wild guess is that you have a "rouge" 192.168.1.0/24 network in the client network that you don't know about, and when you ping 192.168.1.1 or whatever, you're actually getting responses from that "rouge" network and not the one you intended.

Since 192.168.1.0/24 is such a common default subnet, this can happen by accident. Is the client router connected to some other router upstream, say an ISP-provided one? Maybe try pinging a device in 192.168.1.0/24 with the Wireguard interfaces completely disabled to see if you still get a response. If so, you should track down that "rouge" device and deal with it.

1 Like

Yeah.. what you're saying makes sense as I also have no idea why it worked :slight_smile: A rogue device would be a reasonable explanation. I'll check.