WireGuard: allowed IPs - Unofficial WireGuard Documentation

AllowedIPs

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

…

I guess it all boils down to choice between being smart/automatic and flexibility. Since ROS is well known for its flexibility (which indeed overwhelms many less savvy admins) in most of configuration segments, I would expect wireguard configuration to follow the flexibility. But it absolutely has to be accompanied with good documentation.

And copying parts of documentation from generic linux documentation into several forum topics without regard to differences between implementations is not the right step IMO. As much as the effort by @mozerd is well intended, it doesn’t really bring any benefit which posting link to original docs would do … however, the additions by @404Network are valuable for those who might be familiar with the generic documentation and wonder why things behave in slightly different way than described.

@mozerd do you even wireguard on mikrotik?

…

@404 … correct in that my philosophy for networking specifically regardless of type is to be as restrictive as possible and only build to end user requirements … it’s my experience that many people in the IT field neglect networking disciplines where a minimalistic approach is the appropriate way – they only get caught when the auditor brings them to task based on issues exposed.

Latvia is very fortunate to have joined NATO but I an completely disgusted in how NATO has handled the Ukrainian/Russia issue … NATO has abandoned any sense of humanity in not coming aggressively to the aid of Ukraine allowing the Russian Bully to inflict so much pain and suffering without any justification of whatsoever nature. How can moral humans just watch the carnage and just respond with verbal diarrheas’ .

For what purpose ?
To provide a reason to some fool to push the red button ? Because that’s what WILL happen if he gets cornered too much.
And then what ? Bye bye Earth ? To the very least it will be bye bye to most of Europe.
I am not saying what happens now has to happen and we simply need to watch but we need to be very careful about the consequences.

This non-sense needs to stop ASAP. 500% agree.
But more aggression is not always the answer to aggression, certainly not when the bully has some nasty shit in his hands capable of destroying all we know and humanity with it.
Isolation, denial of goods and services, … will also bring him to the knees but it takes longer.
And then his own people will judge (hopefully) but be aware, they have been informed in such a unilateral way for so long already, they mostly don’t know what’s happening nor why. For all they know it’s the West turning completely against them. From that point of view I can even understand normal people are angry towards the West. They don’t know otherwise.

Can we stay at least in broad terms on topic please ?

Which are you more afraid more off … Nuclear, Chemical and/or Biological Weapons’? I am terrified by all of them but that is the reality we face today and its not going away.
Economic Sanctions will not work especially against Russia and China co-operation … they will support each other. Putin/Assad were responsible for 1 Million Syrians dying from chemical weapons’ … perhaps you and many other do not remember that fact. The only way to tackle a Bully like Putin is with extreme force. Putin will not stop after Ukraine he will reconstitute the USSR unless he is stopped COLD.

…

I have contacted MikroTik and requested information as to how the Following WireGuard fundamental Principle is supported in RoS …
When I receive a response I will post it here assuming that they will permit me doing that.

Extracted from the WireGuard Whitepaper

The fundamental principle of a secure VPN is an association between peers and the IP addresses each is allowed
to use as source IPs.

In WireGuard, peers are identified strictly by their public key, a 32-byte Curve25519 point.
This means that there is a simple association mapping between public keys and a set of allowed IP addresses.

Examine the following cryptokey routing table:

The interface itself has a private key and a UDP port on which it listens (more on that later), followed by a
list of peers. Each peer is identified by its public key. Each then has a list of allowed source IPs.

When an outgoing packet is being transmitted on a WireGuard interface, wg0, this table is consulted to
determine which public key to use for encryption.

For example, a packet with a destination IP of 10.192.122.4
will be encrypted using the secure session derived from the public key TrMv…WXX0. Conversely, when wg0
receives an encrypted packet, after decrypting and authenticating it, it will only accept it if its source IP resolves
in the table to the public key used in the secure session for decrypting it.

For example, if a packet is decrypted from xTIB…qp8D, it will only be allowed if the decrypted packet has a source IP of 10.192.122.3 or in the range
of 10.192.124.0 to 10.192.124.255; otherwise it is dropped.

With this very simple principle, administrators can rely on simple firewall rules.

For example, an incoming packet on interface wg0 with a source IP of 10.10.10.230 may be considered as authentically from the peer with
a public key of gN65…Bz6E. More generally, any packets arriving on a WireGuard interface will have a reliably
authentic source IP (in addition, of course, to guaranteed perfect forward secrecy of the transport).

Do note that this is only possible because WireGuard is strictly layer 3 based. Unlike some common VPN protocols, like
L2TP/IPsec, using authenticated identification of peers at a layer 3 level enforces a much cleaner network design.

In the case of a WireGuard peer who wishes to route all traffic through another WireGuard peer, the
cryptokey routing table could be configured more simply as:

Here, the peer authorizes HIgo…f8yk to put packets onto wg0 with any source IP, and all packets that are
outgoing on wg0 will be encrypted using the secure session associated with that public key and sent to that
peer’s endpoint.

@mozerd, something happened to the linked pic:

"… In the case of a WireGuard peer who wishes to route all traffic through another WireGuard peer, the
cryptokey routing table could be configured more simply as:
The attachment wgConfiguration 2a.GIF is no longer available

@Larsa … thank you … your message forced me to use my brain with a guessed fix noted below. …

Yes I saw that … the pic is there but its not placed properly by the forum phpBB software – must be a bug … I tried fixing it but my fix does not work … there is only 2 pics … and both are shown …1a and 2a.

OK I figured out the error and fixed it by changing the numbering scheme of pics …

@mozerd: And what exactly is your question? Peers are identified by they public keys, it’s what the whole WG is built on, it’s same in RouterOS as everywhere else.

…

@ Sob
My question to MikroTik

how does RouterOS provide support for “cryptokey routing” and how to display the cryptokey routing table in RoS?

The only display of keys and associated source IPs etc I see in Winbox and CLI is that shown is under interface … no Routing Table for WG … however I do understand that the Interface/wireguard display can be considered as a Table of sorts but not in the conventional way like … /ip/routing/wireguard

In all my wg implementations under Tik [less than 12} I have not had to manually set routes … allowed IPs did the work very nicely … I see that you plus others … in general terms .., insist on manually setting routes and Yes that under certain circumstance that may be necessary however I have not had those circumstances yet. I have quite a few EdgeMax WG implementations and all work flawlessly without routes manually set. My implementations are mostly end-user driven accessing subnets etc based on site to site and star topologies …

Special Note: All my Wirguard Interfaces have IP addresses assigned and like my simple proof of concept no routers had to be added PERIOD @404

@anav: Yes, roaming works.

@mozerd: No, it wasn’t allowed IPs that added correct routing for you. Allowed IPs only say what the interface supports for each peer, but not what’s actually used. Routing uses regular IP->Routes. If you didn’t add any route manually, it’s because you added IP address with mask covering the subnet you needed to access, and that created dynamic route. Manual routes are needed for other subnets.

@Sob
What does WireGuard AllowedIPs actually do?
Well I disagree with you because The keyword allowed-ips is a list of addresses that will get routed to the peer. That is the WireGuard way

Don’t confuse WG as low level protocol with wg-quick and other high level tools for configuring WG. What you say is only true for the latter.

And about routes, for example:

1. If you have RouterOS as WG server (hate it as much as you want, but you know what I mean), it has 192.168.99.1/24 on its WG interface and clients each get one 192.168.99.X, you don’t need to add any route, because IP address creates dynamic route to this whole subnet.

2. RouterOS as client can have e.g. 192.168.99.20/24 and it will also create route to this whole VPN subnet (so to server and all other clients, and it’s up to server to allow communication between them or not). But if this client needs to access also server’s LAN 192.168.88.0/24, it will need route to that.

That’s what sane people do. Insane ones will:

1. (basic) Not assign 192.168.99.1/24 to WG interface, and instead add route to 192.168.99.0/24 pointing to WG interface. Zero improvement, but feels cool. (*)

2. (advanced) Assign random 192.168.88.X/24 to client’s WG interface. Completely wrong, but definitely original. You can’t beat that feeling. (*)

(*) Resulting feelings may not be accurate and are not guaranteed. Certain unknown level of insanity may be required. Keep away from children.

OK @Sob with the above I CAN Agree

I’m pretty sure the devs are using the standard linux kernel wg-driver as there are no practical reasons why they should tamper with the core implementation, ie ros contains the full wg stack. Apart from that, the main objective is most likely focusing on the parameter settings (ioctl’s) and the tool interface need by Ros.

So anyone interested how the linux implementation of wg is working can have a peek at the source code using the following links:

https://www.wireguard.com/repositories/
https://github.com/torvalds/linux/tree/master/drivers/net/wireguard
https://github.com/WireGuard/wireguard-linux