Hello!
I have a brand new problem with the Mikrotik's WireGuard server implementation.
I don't know from when, but after the latest updates of RouterOS, settings the allowed-address field of the peers configuration with 0.0.0.0/0 or ::/0 gives the allowed-address conflicts other peers error.
Regardless of the fact that this approach has always worked in the past, I find myself in the situation of not knowing how to fill in that field, because I actually have no idea what IP addresses the client will use to make the connection, given that in most cases these are cellular network connections.
In this case, what approach should be used? Is there another way to indicate that the address the connection will come from is unknown?
The allowed addresses are the internal IP addresses allowed through inside the link. These are usually Private IP addresses. In a client/server setup for the Server the allowed addresses is commonly the single fixed IP address assigned to the client's WireGuard interface
Having overlapping IP addresses on different peers (for the same WireGuard interface) has never and can't work reliably. (0.0.0.0/0 is the ultimate overlapping IP) RouterOS Complaining about it seems new though.
No, this is what appears in Current Endpoint Address and has no relation to allowed-address. allowed-address only cares about the addresses inside the tunnel, not the address of the wrapper UDP packets that transport the WG data. That your clients use cellular networks only causes the source/destination of those UDP packets to change. Inside the tunnel the peers should have fixed addresses. and the packets inside the tunnel have addresses not related to the cellular address.
What allowed-address controls:
When the remote peer (for example your mobile phone) establishes the WG connection (with handshake) and start sending packets inside the tunnel to the other side that is the router, the source address of those packets inside the tunnel will be checked against the list of allowed-address associated with that remote peer. If there is no match (including subnet check when you use shorter prefix lengths like /0 or /24, /64, etc....) the packet (that arrives inside the tunnel) are dropped.
When a packet needs to be sent or forwarded (for example from a LAN device) by the router, and the best route (from /ip route or /ipv6 route) for the destination of the packets dictate that the WireGuard interface is to be used as the gateway, the packet to be sent will be handled by the WireGuard interface. WG will look at the list of peers belonging to that WireGuard interface and check the allowed-address field of those peers, the first peer with the best matching allowed-address will be chosen, and the packet will be sent through the tunnel established with that remote peer.
That why there was plenty of threads in the past, were people were unable to have more than one remote WG peers working at the same time. They might create 2 peers associated with the same interface, then give one allowed-address=10.12.34.56/24 and the other allowed-address=10.12.34.67/24 and then wonder why communication with 10.12.34.56 doesn't work at all. Because both 10.12.34.56/24 and 10.12.34.67/24 have the same result as 10.12.34.0/24 when matching with 10.12.34.56, it happened that the peer with allowed-address=10.12.34.67/24 is picked to receive the packet, instead of the one with allowed-address=10.12.34.56/24. But back then if you edit and save the allowed-address=10.12.34.56/24 it will raise in the lookup order and might be picked again. So you have people saying a peer only works if they disabled and re-enabled it. But stops working when they edit other peers.
To prevent that, recent RouterOS version introduced the error and warning messages:
If two or more peers have one (or more) exact same subnet in allowed-address, such as the situation above when one has allowed-address=10.12.34.56/24 and one allowed-address=10.12.34.67/24, which are both allowed-address=10.12.34.0/24, that's an error and you won't be able to save the change, (you see the error message if the peers were already created previously in older versions). Same when both have allowed-address=10.12.34.56/32 for example.
If the subnet are not the same but overlap, for example one has 10.12.34.56/32 and one has 10.12.34.0/24, or one has 0.0.0.0/0, they overlap, but will not produce an error. The range with the shorter prefix (/24 or /0 in the example does contain (which also overlaps) the address with the /32. But it still work because the routing inside WG does honor the priority set by the prefix length. The longer prefix (more precise) will be chosen first if they match.
So with 3 peers, one with allowed-address=10.12.34.56/32, one with allowed-address=10.12.34.0/24, and one with allowed-address=0.0.0.0/0 attached to the same WG interface, a packets destined for 10.12.34.56 will reliably use the 1st peer as destination. And a packet with destination 10.12.35.67 will use the peer with allowed-address=10.12.34.0/24. One with destination 8.8.8.8 will use the 0.0.0.0/0 peer.
So there is no ambiguity, it works that's why you can still save the change and the message is only a warning not a true error message. It's still a warning because normally you probably wanted two /32 peers instead of two overlapping /32 and /24 peers.
But if put allowed-address=0.0.0.0/0 on every peer of the same WG interface then of course it's a big fat error situation.
Normally you only use allowed-address=0.0.0.0/0 (and / or ::/0 for IPv6) for at most one peer per interface, and that's most of the time for the case when you have to route internet traffic through the tunnel (browse Internet via remote WG VPN), in those case the packets to be sent / received have all possible IP addresses and can only be filtered by 0.0.0.0/0 or ::/0.
BTW current Manual contains detailed description of parameters, but only when version 7.24 is selected. For versions 7.25 and 7.26 the parameter reference is no longer available...
You could try assigning each WireGuard peer a unique IP address or subnet instead of using 0.0.0.0/0. The client’s public IP can change on cellular networks, but the WireGuard tunnel IP should remain unique for each peer.
If the WireGuard interface is intended to accept connection from your remote devices like phones and laptops, to allow those devices to access your local resources, or to manage the router, then, as @lurker888 wrote, usually you can put the WG interface in the LAN interface list, especially if you use the default MikroTik firewall (defconf). Because in the default configuration some access like managing the router, or talk to other device through IPv6 is only allowed with the LAN interface list.
But if you create the WireGuard interface because you bought some 3rd party VPN service, and intend use WG to connect to them and direct part of your internet traffic through that VPN, then that interface should be put in the WAN list instead, if you use the defconf firewall configuration. Not only does it automatically apply masquerade to the outgoing connection, but the firewall also prevents incoming connections from the internet, through that 3rd party VPN service, to your router. The WG peer on the other side should be considered as hostile as the internet.
That's because MikroTik has continued to migrate the parameter definitions to the CLI Reference section of the manual. So in the current documentation for version 7.26 the descriptions are now located here:
Thanks. I have missed it as the hierarchy of the CLI somehow differs from Winbox GUI....it will take me a while to digest. ZeroTier and WireGuard has been placed under VPN section in docs, but in the CLI the ZeroTier is directly mentioned while WireGuard is a sub-chapter.... so the muscle-memory has some effect.
Good night, but why did they break the WireGuard logic starting from 7.25? Now there are some address conflicts in the peers that weren't there before. Because of this, you can't update properly to firmware newer than 7.24.x, and even more so to 7.26 to get RPS.
