Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why use /32 instead of /24 for a client's [Interface]? #73

Closed
WinkelCode opened this issue Sep 29, 2021 · 4 comments
Closed

Why use /32 instead of /24 for a client's [Interface]? #73

WinkelCode opened this issue Sep 29, 2021 · 4 comments

Comments

@WinkelCode
Copy link

WinkelCode commented Sep 29, 2021

https://github.com/pirate/wireguard-docs#QuickStart (Step 4.)

I tried looking into it but so far couldn't find a definitive answer, from what I can tell from testing, both /32 and /24 seem to work mostly the same, except that the netmask obviously is different (for example 255.255.255.255 vs 255.255.255.0). So the choice to use /32 seems weird to me as it would (from my understanding) mean that any traffic would come from outside the client's own subnet.

I understand why one would use /32 in the AllowedIPs for a peer (to prevent peer's netmasks overlapping) but I don't understand why use it in a client's [Interface] config.

Looking at the various guides and documentations from reputable sources there doesn't seem to be a consensus and both /32 or /24 are being used in examples.

Edit: Examples:

/24:

https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-20-04

https://wiki.debian.org/SimplePrivateTunnelVPNWithWireGuard

The Quick Start video on the official WireGuard website: https://www.wireguard.com/quickstart/

/32:

https://docs.opnsense.org/manual/how-tos/wireguard-client.html (mentions matching client's [Interface] to server's AllowedIPs)

https://upcloud.com/community/tutorials/get-started-wireguard-vpn/

https://www.thomas-krenn.com/en/wiki/Ubuntu_Desktop_as_WireGuard_VPN_client_configuration

@gtrabanco
Copy link

In the server when you are using /32 you also configuring a route for specific ip address through that peer. It is a routing concept.

For example you have route to network /24 through one link A but any specific IP is reachable through other route, you should specify a static route with the ip with CIDR /32 through whatever route is necessary to take.

@WinkelCode
Copy link
Author

In the server when you are using /32 you also configuring a route for specific ip address through that peer. It is a routing concept.

For example you have route to network /24 through one link A but any specific IP is reachable through other route, you should specify a static route with the ip with CIDR /32 through whatever route is necessary to take.

Isn't that AllowedIPs stuff?

So from your example

[Peer]
#Peer 1 - Entire Subnet
AllowedIPs = 10.0.0.0/24
[Peer]
#Peer 2 - Just one IP
AllowedIPs = 10.0.0.2/32

@gtrabanco
Copy link

Yes

@pirate
Copy link
Owner

pirate commented Sep 29, 2021

They serve different purposes @gtrabanco, /24 = route all traffic to the rest of the subnet through this node, /32 = only route traffic destined for that specific node to that node.

More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the 192.0.2.1/24 catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (net.ipv4.ip_forward = 1) back down the VPN to the specific peer that's accepting routes for that traffic. WireGuard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in [Peers] to least specific.

https://github.com/pirate/wireguard-docs#how-wireguard-routes-packets

If a client has an interface to a node with /24 set, it will route all of its traffic to any address on that /24 to that node, even if that node isn't the final destination for the traffic itself (e.g. it could be a relay node that then bounces that traffic to the next hop). Whereas if a client has a /32 set for an interface with a node, it will only send traffic destined for that node to that node. The more specific (i.e. the smaller the CIDR range) a given interface can handle, the higher precedence it gets in the routing rules.

Wireguard is not an automatic mesh network, you are responsible for setting up the routing manually using these /32, /24, etc. specifiers. The examples you're reading often have both because they're trying to demonstrate both cases and show the user that you will have to decide on your own based on what routing pattern you want.

@pirate pirate closed this as completed Sep 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants