Hi everybody
I'm using LuCi to setup the wireguard interface and everything works so far but saw that you can add
ip/mask for allowed dst IPs.
My task is actually having multiple wireguard peers. Yeah, I would set 0.0.0.0/0 for each of them for allowed dst IPs but I cannot see src IP rule in order to set only some private ips going trough the tunnel.
How to achieve that ?
I have another complication that the private IPs allowed to go trough the tunnel Peer1 are the following wildcard 10.???.???.??9 (for example 10.0.0.29, 10.0.0.39, 10.1.1.19 etc.).
although Wireguard doesn't really have a distinction between 'server' and 'client' peers, it can helpful to establish the purpose of each end point as such.
The 'server' is usually the one that is listening for inbound connections. In the case of a road-warrior type VPN config, the server would be at your home or business, and the client would be the one you have with you at a remote location.
In this context...
The server's configuration includes an interface stanza and then one or more peer config stanzas. In each of the stanzas, you will set a single /32 address. So if you have an interface stanza that uses (as an example) 10.14.15.1/24 as its address, you would usually have peer config stanzas that would have allowed_ips set to 10.14.15.2/32 and 10.14.15.3/32, and so on.
On the remote peer ('client') device (say a phone or laptop), you would have the interface address as 10.14.15.2 (you can use /32 or /24 here -- doesn't really matter). Then, on that device, the allowed_ips would be 0.0.0.0/0 if you want all traffic to traverse the tunnel. Or if you want only specific traffic -- say access to the lan on the 'server' side -- you would set it to that network address (let's use 192.168.50.0/24 as an example). You can have individual addresses or whole subnets, and you can list multiple ranges as needed.
In this configuration, your remote (client) peer configuration's allowed_ips field is the one that is determing what should go through the tunnel... this is fine if you trust the devices/users and don't need to set limits should someone edit the wg config file on the peer they have in front of them.
If you need to limit what the remote ('client') peer is allowed to access on the 'server' side, you would do this with firewall rules (on the server side) to allow or block at whatever granularity is required.
If you have specific examples of what you are trying to achieve, we can guide you through the process.
Thanks for the reply. I don't have access on the remote peer to do anything as it is VPN (not a VPS or Dedi) service, so everything has to be done on my router config.
My task is to distribute the private ips using the correct tunnels.
Private IP address on the LAN iface (any p ip ending with 9) must use Peer1.
Private IP address on the LAN iface (any ip ending with 8) must use Peer2.
You can call it limit access as well, although I think it is more like "distribution".
Otherwise, yes I'm already running the VPN client on my router with wireguard as I mentioned but only trough 1 peer for all LAN IPs.
What comes to my mind as option is probably having mutliple wireguard interfaces with single remote peer. And do something with the firewall but this may be more CPU intensive and seems even more complicated on first look.
Wireguard doesn't distribute IPs at all. They must all be pre-determined and configured on both peers.
I'm not sure if the OpenWrt side is acting as the server or client...
What is the remote peer? Is the remote peer trying to gain access to resources on the local network on the OpenWrt side (or through the OpenWrt device to the internet), or are local devices trying to access resources that exist on the remote peer side?
The remote peer for OpenWrt is in fact the VPN service.
VPN service does not gain any access to the OpenWrt LAN and it is trusted. Its purpose is to provide internet from another location on the world to the OpenWRT (client) and its LAN network.
"local devices trying to access resources that exist on the remote peer side" - yes and the resources are - internet.
This is already done, but the problem is to let specific LAN ip addresses on openwrt access specific remote peer.
ok... now I understand. So you have an OpenWrt router with multiple 'client' peers configured, and you need to steer some local clients to use one peer, and others to use the other peer.
If that's a correct understanding of your situation, you should look at policy based routing.
The thing is.. a peer does not have any recognitions which I can think of. A peer is made of keys and endpoint host, PBR needs ip addresses or firewall marks for recognition purposes.
I can't see anywhere the endpoint host (ip or domain) included in the firewall (cgi-bin/luci/admin/status/nftables/iptables)
although my wireguard is running fine, which makes it difficult to understand how the heck wireguard is already "steering" my LAN ip address towards the peer.
The other known thing is the wireguard interface name (wg0) which can be used in PBR, but again, there's no refined control and identifying peer1 or peer2 inside the interface. I'm going to need a command example if that's possible.
Edit: the "ip route" command shows some signs of routing "but I have to invent the mathematics again".
If you want to use 0.0.0.0/0 for different endpoints then you will need to set up multiple wireguard interfaces. You can't use the same (or overlapping) addresses as 'allowed IPs' for multiple peers within a single WG interface.
Sure you can, you just can't have routes auto created for those peers.
LE: I've never tested this and I take the statement back, so nope, even with table=off it won't work, even if you manage to write such a broken config using the various helpers/GUIs, it will still be nonfunctional.
If you have a VPN provider and you want to setup routing to multiple places you can make multiple tunnels each tunnel with only one peer.
I have a VPN provider (Mullvad ) and have setup a tunnel to France and to Roumenia, so two tunnels (each with its interface of course).
Then I use Policy Based Routing to route some of my LAN clients to use one tunnel and some to use the other (and you can also set some destinations to always use a certain tunnel etc.)
Yes, this is what I want but, this means multiple interfaces which I was afraid of. Maybe this is more CPU intensive than 1 interface with multiple peers ?
Also, I have the complication that I need 10.0.0.19, 10.1.1.19 (wildcard ips ending with 9) etc. for 1st peer and 10.0.0.18 (wildcard ips again as above but ending with 8) for 2nd peer.
How would that happen on PBR, maybe something with ipset or something ?
No, you really can't. WG maintains an internal routing table for the peers for each interface. It won't allow you to run multiple peers with the same 'allowed ip' addresses. I believe you can get away with a peers that use more specific addresses/ranges than an already existing peer, i.e. use a /24 on one peer and then a /32 from the same range on a different peer. But you couldn't have overlapping ranges where it wouldn't be clear where the packet should be routed.
It probably isn't. Wireguard isn't chatty so should only be using a significant amount of resources when actually sending/receiving traffic. Whether that's multiple interfaces or multiple peers within an interface shouldn't make too much of a difference.
Is there a reason for this addressing scheme? It seems to be adding unnecessary complication.
That is apparently something that you just made up, as IPv4 and IPv6 standards are built around prefix-based routing. The standards compliant way to have groups of hosts within the same IP prefix is to break the overall prefix into smaller prefixes. For example overall start with 10.1.1.0/24, this can be split into four /26 prefixes 10.1.1.0/26 --> 10.1.1.1-62, 10.1.1.64/26 --> 10.1.1.65-126 etc (In IPv4, the first and last possible number in a prefix is reserved and can't be assigned to a host). Each of the /26 prefixes can then be used as a PBR source into a different tunnel for VPN destinations, while a local routing table can use the overall /24 to collect all of them.
Unfortunately for src IPs for /8 network probably I need tool that is accepting wildcards and I really hope ipset does. Yes, at the end that's gonna be thousands of CIDRS to match, but it is up to the tool to decide not 100kb list of CIDRs that I have to build myself.
When a packet is sent into a wireguard interface to be encrypted and dispatched to a peer, Wireguard does use a routing table process to determine which peer to send it to. The table is built out inside Wireguard from the allowed_ips as they are entered into the kernel. The same rules are used as the regular kernel routing tables: it can't have overlapping routes with the same prefix, and longer prefixes (more specific routes) are considered first. I don't think there is a way for userspace to examine the resulting table.
The additional layer of routing is necessary because each peer has a unique encryption key and a unique "outer" IP:port on the Internet. Wireguard needs to know which peer in order to build and dispatch an encrypted packet. Speculative broadcasting to multiple peers is not supported.
If a Wireguard interface has only one peer, both sides can configure allowed_ip as the whole address space (a zero prefix: 0.0.0.0/0 or ::/0). Then the internal Wireguard routing table is moot as every packet submitted to the wg interface will be encrypted and dispatched to the one other peer. The decisions how to route a packet would then be entirely outside Wireguard.
It really isn't. But if you don't believe me, try setting up a wireguard interface with two or more peers using the same allowed IPs and prove me wrong. I'll happily retract my statement if you can show an output from wg show showing a working setup.
krazeh it won't work because there's no source ip routing. If there is source ip routing to "steer" the correct lan address to selected peer it must work. That's my opinion and I guess @znevna 's
