Possible to allow custom IP Mask on Server (Not /24) for clients

[nunnsby]

On creating a Server IP, even if I assign it a /27, it still outputs it as a /24 when assigning the clients. Not a train smash, but would be nice if you could pull in the mask defined and then use it for the clients.

I would recommend stating that the mask needs to be defined, such as /24 - /30, (understanding that some people might want bigger ranges for a lot of clients, especially now (Covid and more requirements to work remotely, so some people might want a /23, /22, /21, etc)), and then carrying that value across to the clients.

I'm not a coder, but I've had a look, and think that you are setting it manually in: https://github.com/perara/wg-manager/blob/master/wg_dashboard_backend/templates/peer.j2 Address = {{ data.peer.address.replace("/32", "/24") }}

On a separate note, I'm running it in docker and works like a charm. Amazing. Such a great product. Nice work. :)

[perara]

Seems reasonable: Would this be valid configuration if i were to use a /15 mask?

[Interface]
Address = 10.0.200.1/15
ListenPort = 53522
PrivateKey = QEmwrgLdKG2f/yPrqL7ZwX1Tjn0rm99gzZR5sg6I5VI=

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

[Peer]
# Client Name: Unnamed
PublicKey = Dq0BLdjSGzR0AHFtBuT0419w5D6U/Wdtlom0aHRjEFE=
AllowedIPs = 10.0.0.1/32

Client:

[Interface]
Address = 10.0.0.1/15
PrivateKey = sAm8t7J7g+JJsSD8341E9olFLF17xiHO83MpPFW9UFg=
DNS = 

[Peer]
PublicKey = CSgp0Zq9CtHpH260WJym1YikRRYVv9SPmsSh4x+YcBI=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = sysx.no:53522

Edit: I would assume that the server configuration is correct, But I'm unsure about the client, specifically the Address field.

[nunnsby]

So, a /15 is valid, but it is a massive range, with 131,000+ hosts in the subnet. Not impossible, but highly unlikely. (http://jodies.de/ipcalc?host=10.0.0.1&mask1=15&mask2=)

The subnet and mask is usually designed and built according to the number of hosts you wish to have per subnet, and in the case of a vpn server, typically the number of clients you wish to serve per server (usually).

A /24 gives you 254 hosts, typically enough, but in these times I have seen instances personally of /23 (512), /22 (1024), /21 (2048), /20 (4096). Hardly ever greater than that. Most usually because it is a large block of IP space you are consuming in a company private range. I think allowing the person to chose the mask (/anything) is probably sufficient. I personally make mine small (/28) which usually gives 14 usable addresses (including the server), as I have a number of devices, but I come from a networking background, so choose to do things that way.

In general, if I chose a /24 for the server, ths would be a range of 256 addreses. 2 are lost (network and broadcast by default) so that leaves 254. The server in this case is like the router in most networks, and is "usually" set at either .1 or .254 in the subnet. Creating a client with a /32 is fine as what it means is that when the client joins, it is usually not routing anything behind it through that link, so you usually only want to get to that device, the /32 from the server. Allowing people to then manually amend the range on a per device basis is fine.

It was just in your case currently, even setting a custom range on the server still applied a standard mask of /24, which is not ideal.

In my case I would I set the server as 192.168.255.1/28 Server = 192.168.255.1 Client = 192.168.255.2

The client config would show the server of 192.168.255.1/28. Client of 192.168.255.2/28. This means that the client knows that there could be .3 -> .14 on the same subnet as itself, which means you could allow for device to device comms (if you wanted).

The Server sees the client as 192.168.255.2/32, meaning all it knows is that the device is a single device (the most specific ip address route of a single device = /32). If you wanted other networks behind the device you would advertise/add those networks to the client config on the server.

Leaving the server as a default of /24 should be fine, but I would state that it is the default, and let people change it if need be, and allow the change to carry if they do.

Hope that all makes sense.

[perara]

Hi and thanks for the detailed explaination :) Yes, /24 is set as default, but ive made it possible to define any mask (1-32).

I know generally of how subnetting works but not sure of the following:

Suppose i set the server address to 10.0.0.1/20, would it be valid to define the client.conf address as 10.0.0.5/24 or should/must the mask be same for both client.conf and server.conf?

Ill elaborate if the example is unclear

[nunnsby]

Hmmm, thinking about it, yes it is a valid configuration, but one we would usually steer away from. The client "should" always match the subnet of the server. As this tells it what is on the same subnet as itself, or what is off the subnet. In this case however, as the client is always on a "point to point" link (always communicating with the server), it will always talk to (through) the server (gateway) regardless.

However if you do do that ,implement a /24 in a /24 subnet, (I suspect you want to make it easier to manage and implement) then the client subnet MUST always be equal to, or smaller than, the subnet of the server. Meaning if the server is /20, the client must be /20 or less (/21, /22, /23 ....). If the server was /24 and the client /20, the client could think a device in the same /20 (that is not in the same /24 subnet) is on the same subnet and would possibly never talk through the wireguard server. I say possibly, as I am not sure how WG implements the communications. I do assume all comms from the client, regardless of the IP addressing, will actually go to the server. In an IP world on any standard subnet, the comms will always "broadcast" and in that case would go to/through the default gateway to get off subnet. So I am assuming WG is NOT fundamentally breaking the rules of IP.

So, if you wanted to implement a /24 for clients in a /20, you can, but it is usually seen as not done.

[marshallstokes]

Looking forward to this. There is a strong case to be made in favor of using /32 as the default client mask for security. Seems like most wireless APs effectively do this with "AP Isolation" enabled out of the box.

Regardless of the default value, we must have the ability to set each client IP mask to be written to configs. Do you have a docker image available for testing? I would be happy to run it through the ringer a bit.

Edit: Actually I don't know if this is so much about "AP isolation" style functionality as WG's internal routing functionality. Will follow up if I can sort out what I am experiencing in my basic /24 setup.

[perara]

Hi, I've added the functionality in the dev branch (sorry forgot to actually make the branch). https://github.com/perara/wg-manager/tree/dev

Edit: https://github.com/perara/wg-manager/blob/master/README.md#using-the-development-branch

[sputnic42]

I just tested the non-dev docker build and found some inconsistencies at the client config generation:

I set the server to a /25 subnet and added a client the following configurations had been generated:

[Interface]
Address = 10.0.200.128/25
[...]
[Peer]
# Client Name: Unnamed
PublicKey = xxx
AllowedIPs = 10.0.200.129/32

So far so good

But the client configuation is somewhat broken: Although the "Address" field in the UI says (correctly) 10.0.200.129/32 the configuration itself shows

[Interface]
Address = 10.0.200.129/24
[...]

So it seems the subnet size just defaults to 24 in the confguration file if the length is set to 32. Mask lengths manually set up to 31 get set correcty in the file.

[perara]

Thanks for testing. I'll check this out

[perara]

I think this is fixed. I believe the bug appeared previously as configs did not generate properly between peer/server changes. However, now this should change after all changes.

With this, I also think the feature is good 2 use :)