I managed to configure wireguard to be accessible by one client.
What I would like to do now is, ....
make the server accessible by multiple clients simultaneously
run the server on port 443
move the server and client config to "/etc/wireguard/wg_server.conf and wg_client.conf" so that I don't have endless lines of code in my network config file.
Number one priority for me is to have the config like below, so I can have multiple clients connect to the server at the smae time. I already tried many different ways to achieve my goal, all of them leading to an inaccessible wireguard server.
wanted config in /etc/config/network
config interface 'wg_server'
option proto 'wireguard'
option private_key 'private_key_server'
list addresses '10.13.56.1/24'
option listen_port '50001'
config wireguard_wg_server
option description 'client_A_pc'
option public_key 'client_A_public_key'
list allowed_ips '10.13.56.31/24'
option route_allowed_ips '1'
option persistent_keepalive '25'
config wireguard_wg_server
option description 'client_B_pc'
option public_key 'client_B_public_key'
list allowed_ips '10.13.56.32/24'
option route_allowed_ips '1'
option persistent_keepalive '25'
config wireguard_wg_server
option description 'client_C_pc'
option public_key 'client_C_public_key'
list allowed_ips '10.13.56.33/24'
option route_allowed_ips '1'
option persistent_keepalive '25'
and so on.....
I hope you guys can point me in the right direction.
I'm not aware of a way to do this on OpenWrt, but if you do find one, that would be cool to learn about. Fundamentally, since this needs to be part of the WireGuard interface definition, you would need to have a config include in a similar way as the /etc/config/firewall file specifies the /etc/firewall.user file for inclusion. I don't believe that this technique is supported in the network file, though. This would be a cool option for development, especially if combined with some additional work on the LuCI app for WG where the status page could be combined with the peer config.
Wireguard works as a p2p network, and each peer must be on a /32 because it is specifying a single host, not a network. I don’t know how to explain this better or why the protocol was coded this way. But I did run some experiments recently and proved that it must be /32
Wireguard works perfectly well with routed subnets. I currently have 3 peers set up that way, i.e. the 'allowed_ips' in the server config are a /24 subnet.
The reason for needing to put /32 in this case is the OP is specifying a single address, not a subnet.
@krazeh - are you sure? Care to share your config files (keys redacted, of course).
Based on my tests, the peer config section on my router (the ‘server’) absolutely had to be set with allowed ips as /32. But the remote peers could set allowed ips to full networks, including 0.0.0.0/0.
Edit: on the wireguard website, they show the server side config with a /32 and then optionally other networks.
The first allowed ip is a /32 and represents the interface address allowed for the peer. The second entry specified the routed access that the peer will have, in this case a /24 network. I believe that this limits the peer to only have access to that specific network, while if not specified the peer can connect to any routed network (including the internet), based on how the remote peer allowed ips is set.
As you can see, all routed subnets, not a /32 in sight.
As I understand it, Wireguard doesn't really care about the routing, the 'allowed_ips' is just use to determine what traffic is allowed into the tunnel from each end. In your example from the wireguard site, it means traffic for 10.192.122.3 and the 10.192.124.1/24 (altho I assume they mean 10.192.124.0/24) subnet will be allowed into the tunnel on the server side. Without seeing the 'client' config it's not possible to say what traffic will be able to enter from that end.
Problem #1 is now solved. I can have multiple clients connect at the same time.
My error was that I changed config wireguard_wg_server to config wireguard_wg_server_client_a and so, for each client...
What is this bit for?
Especially why do you define allowed_ips twice? Isn't the second line obsolete?
Is there a reason that you give your phone an entire subnet and put your surface on another one?
Why don't you just put them all in the same one? Like I did and increase the IP by 10 or so?
Back to topic:
How can I run the server and clients on port 443? Do I need to change anything in the router config for this to work besides the wireguard config?
I have two vlans locally. One has access to only the lan at the other end of the wireguard tunnel, the other routes out to the internet. I probably could remove the second line, but it was already there and it causes no harm being there.
I just do that for any peer I add. There's plenty of private IPs available so why not use them?
Hmmm... I would think that this is not the correct use of the allowed IPs field, but if it is working, more power to you!
One major difference I'm seeing between your config and mine is that you haven't defined an interface address/subnet for WG on your router. So every peer has its own subnet, which is interesting, to say the least. It would not be efficient if you had thousands of peers to worry about (say corporate or a VPN provider), but in a home or smb environment, efficiency of IP addressing doesn't matter.
What would happen if you had two or more remote peers on the same subnet (for example, if your surface had the allowed IPs of 192.168.20.0/24, same as your iPhone)?
Why do you think that? The point of the allowed IPs field is to tell wireguard a) which peer to send packets to and b) whether to allow a recieved packet through. Don't think there's any other rules beyond that about its 'correct' use.
The router running WG already has a public and private IP,. WG internally routes between the two. No need to bother with an unnecessary additional IP allocation. And no, it probably would't be that efficient for large volumes, but then again you can get over 65000 /24 subnets out of the 10.0.0.0/8 network.
As it is, I don't need to give each peer a separate subnet but it means I don't have to think about what free IPs I have locally for allocation. And if I do want add a peer which has multiple hosts behind it (such as a travel router) I can just run DHCP on the peer to deal with IP allocations.
Well if Wireguard didn't throw a hissy fit and refuse to run, I'd guess it'd keep updating the routing table with the endpoint address for whichever peer connected or did a handshake last, which would theoretically give you access to/from one peer for a short period before it flips to the other one and so on (assuming they're both running). In short, it probably woudn't work. Not sure why you would give two peers the same subnet tho.
list allowed_ips '10.13.56.31/24'
I now have this set to list allowed_ips '10.13.56.31/32', which is indeed the right way to do it.
Even though it was working before, but wireguard wiki also says to do it with /32 .
Based on my empirical data, a /24 will work if you have exactly one peer defined on that network. If you have multiple peers on the same network (even if they are not active), it will fail unless it is a /32.
I suspect that @krazeh's WG config works specifically because there is only one peer defined on each subnet.
I personally would always recommend using /32 -- not only does it reliably work now, it is, by design, how the protocol is supposed to work, and it is essentially guaranteed to continue working (save for a major architectural re-design of the protocol), whereas any other peer network definition could fail to work with future versions of WG.
Well yeah it would. Assigning the same address to different peers is a bad idea whether it's a /24 subnet or a single /32 address.
I disagree, if you read the detail of how wireguard works and how it makes decisions on what to allow in and out of the tunnel then it's clear that it's entirely flexible about what addresses you use. There's nothing which states a clear requirement to have a separate subnet from which you assign a specific /32 for each peer, nor has it ever been a requirement to actually make it work in practice.
If you're connecting to a single device, and will always be connecting to that one device, then yeah use a /32 in the allowed ips. If, however, you're doing something like a travel router and will be connecting multiple devices, or are doing a site to site vpn, then it makes far more sense to use a /24.
I have multiple devices, including a travel router. So, for example, at my dad's house, I have an OpenWrt router setup specifically as a VPN endpoint. It runs WG, of course. I have 3 peers defined (my desktop computer at my house, my iPhone, and my travel router). They all have unique addresses (and are each /32) but would be on the same subnet if viewed as a /24. I have a similar setup for my in-laws' house and for my own home. I experimented with the same addressing scheme but with non-/32 setups (so for example, 10.0.56.2, 10.0.56.100, etc.). Even if I made that each /31, it would still fail, even though they do not overlap. They must be /32. Period.
I have looked at the WG documentation, and I cannot find anything that supports your assertion that the peer address can be a /24 for example. Every example I see in their documentation has at least one /32 associated with each peer. There may also be /24 or other sized networks, but from what I can tell, those are the allowed access (and if left unspecified, it is the equivalent of allowing 0.0.0.0/0 from a routing perspective).
In all cases, the first address in the AllowedIPs field is a /32. In some cases, it is followed by future allowed IPs (which I believe restrict routing to those networks or hosts).
@krazeh - Can you point me to a specific example from their documentation where a peer assignment is a anything other than a /32 as the first (or only) address in the AllowedIPs field?
This defines the IP ranges for which a peer will route traffic. On simple clients, this is usually a single address (the VPN address of the simple client itself). For bounce servers this will be a range of the IPs or subnets that the relay server is capable of routing traffic for. Multiple IPs and subnets may be specified using comma-separated IPv4 or IPv6 CIDR notation (from a single /32 or /128 address, all the way up to 0.0.0.0/0 and ::/0 to indicate a default route to send all internet and VPN traffic through that peer). This option may be specified multiple times.
When deciding how to route a packet, the system chooses the most specific route first, and falls back to broader routes. So for a packet destined to 192.0.2.3 , the system would first look for a peer advertising 192.0.2.3/32 specifically, and would fall back to a peer advertising 192.0.2.1/24 or a larger range like 0.0.0.0/0 as a last resort.
Examples
peer is a simple client that only accepts traffic to/from itself AllowedIPs = 192.0.2.3/32
peer is a relay server that can bounce VPN traffic to all other peers AllowedIPs = 192.0.2.1/24
peer is a relay server that bounces all internet & VPN traffic (like a proxy), including IPv6 AllowedIPs = 0.0.0.0/0,::/0
peer is a relay server that routes to itself and only one other peer AllowedIPs = 192.0.2.3/32,192.0.2.4/32
peer is a relay server that routes to itself and all nodes on its local LAN AllowedIPs = 192.0.2.3/32,192.168.1.1/24
...............
Address
Defines what address range the local node should route traffic for. Depending on whether the node is a simple client joining the VPN subnet, or a bounce server that's relaying traffic between multiple clients, this can be set to a single IP of the node itself (specified with CIDR notation), e.g. 192.0.2.3/32), or a range of IPv4/IPv6 subnets that the node can route traffic for.
Examples
Node is a client that only routes traffic for itself Address = 192.0.2.3/32
Node is a public bounce server that can relay traffic to other peers
When the node is acting as the public bounce server, it should set this to be the entire subnet that it can route traffic, not just a single IP for itself.
Address = 192.0.2.1/24
You can also specify multiple subnets or IPv6 subnets like so: Address = 192.0.2.1/24,2001:DB8::/64
