Wireguard: server with multiple clients

@shm0 - Thanks fo that info... very useful.

Meanwhile, @krazeh - aren't your devices effectively "simple clients" in the parlance of the WG definitions? If they're not relay servers, they should be /32.

Except they don't need to be a /32. I've just altered my config slightly to use 192.168.3.0/29 and 192.168.3.8/29 as the 'Allowed IPs' for two of my peers. These are obviously subnets of the larger 192.168.3.0/24 network. Both peers connected and passed traffic back and forth with no issues. If you were having failures then it's far more likely it was an issue with the addresses you were using (overlapping ranges, invalid addresses etc) rather than a restriction on the part of WG.

No, but they are examples so are designed to be able to explain a wide range of concepts. You have to read the text around that example, so details of the 'Simple Network Interface' and ' Cryptokey Routing' to properly understand what the 'Allowed IPs' field actually does. It's not a method to assign remote IPs, that is done at the remote end. It's a routing table at the local end, and a access control list at the remote end.

Just to be clear, the definitions from the examples posted by shm0 are from unofficial documentation. They're not, afaik, "WG" definitions from official WG documentation.

But, in the spirit of answering the question, yes two of my three peers are "simple clients" and I could limit the 'allowed IPs' for them down to a /32 to only allow traffic for whichever specific IP I assign locally on the device. I've never disputed that I could do that or that it would work just as well for a single device peer config. However, my point has always been that there is no requirement to do so, nor does the concept or practical implementation of WG care about how you choose to assign IP addresses to your networks or devices. All it needs to know is where to route any traffic it receives.

Pretty certain that's incorrect as far as the implementation on OpenWRT goes (and quite possibly for Wireguard as a whole). The address field lets you assign an IP to the interface, it doesn't then go onto be used to determine what addresses can be routed through the interface.

It does set the IP and subnet mask of the interface.
If a improper subnet mask is specified no routing is possible, I guess?
Setting this to */32 makes no sense? Or does */32 work for Point to Point connections?

Yeah, it does make little sense to do that. But as long as the address is valid it doesn't seem to have any impact on whether it will route or not. On my local 'server' WG interface I've tested it with no address assigned, a /24 address, and a /32 address (in the latter case both addresses were taken from the subnet being used in my local LAN). I was still able to connect with remote peers, pass traffic back and forth, and access resources in a remote LAN.

I think it only has impact on clients connected over the wg tunnel.
Using a /32 mask doesn't allow clients to communicate to each other.
Using a larger mask allows communication.

Did you try to set both address and allowed IPs on the server interface?
What does happen if you use /32 for address and yourwgsubnet/32 for allowed IPs.
Can you still access your local lan?
//edit
Okay, I tested this setting a */32 address on the server results in a none working state.
I even can't ping the server. I have to reduce the mask to /30.
Setting allowed IPs has no impact.
So address = simple IP/mask setup
allowed_IPSs = only effects traffic going through the tunnel (when connecting as peer), I guess?
So they only way to limit the routing on the "server" side is by setting up proper firewall rules.

So, my local LAN uses the 192.168.1.0/24 address range and my router has the address 192.168.0.2/24 assigned to the LAN interface. Wireguard connects to a remote router that is part of a LAN using the 192.168.0.0/24 address range. Locally I have 192.168.0.0/24 in the 'Allowed IPs' for the remote peer, and remotely I have 192.168.1.0/24 in the 'Allowed IPs' for this local peer.

Up until today I had no address assigned within the WG interface locally. I've now tested with allocating the address 192.168.1.12/24 and 192.168.1.12/32 to the interface. I even allocated an address outside of anything I use (192.168.5.47/24). In each case the address shows up on the interface (confirmed through ifconfig), but it has no impact on my ability to ping or access hosts on the local or remote LAN, from either end.

The only impact I did see was where I used 192.168.5.47/24 which stopped me being able to ping hosts on the remote LAN directly from my router. I had to add 192.168.5.0/24 to the 'Allowed IPs' on the remote side to get this working again. But I would expect that as the ping would be coming from 192.168.5.47. Could ping local hosts from the router fine and can ping 192.168.5.47 from local hosts (and now remote hosts) fine. Have also tried this with 192.168.5.47/32 and it all continues to work. Everything can ping and access everything else.

From the testing I've done it just reconfirms my understanding of how WG works. All it really cares about (when it comes to passing traffic through the tunnel rather than authenticating keys etc) is what is in the 'Allowed IPs' field. I think the difficulty with understanding WG is that there isn't really a server-client model. All peers are equal so you have to consider both sides.

It's one way. Not the only way tho. You could give connectivity between specific hosts on separate LANs by only using their IP addresses (i.e. x.x.x.x/32) on the respective ends of the tunnel. Or you could use smaller subnets to only give access to certain hosts (assuming you'd set up your LANs in a way that would make that feasible).

wireguard tunnel interfaces don't really need an ip address at all if there's a router on each end. in fact this is the easiest situation.

if one end of the tunnel is a non routing host, such as a laptop, then by putting an ip on its wireguard interface you make it easier for the laptop to provide an ip that is allowed by the remote host. that's the only reason to put an ip on the interface.

allowed ips on a given machine are the ones its remote peer is allowed to send through the tunnel, nothing more. if host A allows xxxxx/y then host B can only send packets from the xxxxx/y range.

also wireguard works great with ipv6. in my opinion for a VPN there is very little reason to use anything but ipv6. for all my wireguard tunnels I route/allow the entire remote ULA prefix.

If you have some legacy service that doesn't support ipv6 you can use ipv4 of course but that's an increasingly small amount of stuff. heck even Minecraft supports ipv6 :hugs::partying_face:

2 Likes

Without IP(/Mask) on an interface, it is quite impossible to route packets over this interface?

The router already has, in most cases, WAN and LAN IP addresses. It doesn't need a further IP address on the WG interface to route packets internally.

Is it possible to run wireguard on udp port 53 without issues?
(To avoid blocks in certain networks)

It is probably not recommended, but sure, try it. You can theoretically run WG on any port you desire.
Keep in mind that this may still not bypass certain network blocks unless you know for sure that they allow the use of any arbitrary DNS server. If they have outbound port 53 blocked and/or redirect DNS requests to an internal service (i.e. pihole, etc.), or if they only whitelist specific DNS servers, you may still find that you cannot reach your WG peer/server.

1 Like

Do you have any other port suggestions to run wireguard on, so I can connect to my server from most places?
Any other standard services that use udp protocol?

Feel free to look yourself:

Most ports in the ephemeral ranges and VoIP ports are usable.

1 Like

More generally speaking (based on my limited experience), each public key/peer needs unique list of allowed IPs.