My router is rb5009 with the 7.0rc6 version of routeros.
My problem is one wg interface can’t add multi peers. If the second peer set, first one will be can not connect.But second peer can get connection. Delete second peers. Fisrt also can not connect.
Does any one have the same problem with me?
Hello,
please post the output from:
/interface/wireguard/export
Have the peers the same public (peer) key?
Shouldn’t be possible to create a second peer with the same public key. An error should be presented.
The jury is still out if THAT behavior is a bug or a feature 
no each peer have it own public key
hi jookraw
nov/19/2021 07:45:08 by RouterOS 7.1rc6
software id = RRC7-KUDQ
model = RB5009UG+S+
serial number =
/interface wireguard
add listen-port=51821 mtu=1420 name=home-vpn
add listen-port=51822 mtu=1420 name=vpn-zhou-1
add listen-port=56722 mtu=1420 name=vpn-zhou-2
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=*************** endpoint-port=51822 interface=vpn-zhou-1 public-key=“IHDyT7r6sQ33u1Ie7fAAX1opzq7VEt0BJjx2Allwpzo=”
add allowed-address=0.0.0.0/0 endpoint-address=*************** endpoint-port=5603 interface=vpn-zhou-2 public-key=
“SAi/J9qI+htWD3C/MVjwhqDmnNt5uEMm2JKFxeYt0Eg=”
add allowed-address=0.0.0.0/0 interface=home-vpn public-key=“leq6TcW70L/381zmBIiVIp5H18FhG1H0z3R6Iq7yzW8=”
add allowed-address=0.0.0.0/0 interface=home-vpn public-key=“rVR+SMf90M/EvjEeUwS1Dd+ji8B/nHTmZR4wqGQuxBI=”
This is the problem. When having multiple peers on a single interface, wireguard uses the allowed-address setting to determine which peer the packet should be sent to. If the destination IP of the packet is in allowed addresses for the first peer, it will be sent to the first peer. If the destination IP is in the allowed addresses for the second peer, it will be sent to the second one. You have defined your allowed addresses as 0.0.0.0/0 which will match absolutely everything to both peers, but it would probably check the first peer first and then the second peer would never receive anything.
thank you very.
Because site to site vpn is not any problem with 0.0.0.0/0. So i make a mistake. Thank you for your help
How I can use allowed-address if, I have two peers behind NAT? Their addresses are dynamic.
I have only one wireguard interface on main router.
My trouble is: OSPF doesn’t working on this configuration correctly.
Main router: I can’t use 0.0.0.0/0 on both peers, because " When having multiple peers on a single interface, wireguard uses the allowed-address setting to determine which peer the packet should be sent to.". If I using on the first peer: allowed IP 172.16.17.217/28, and on the second 172.16.17.217/28: ping working good.But OSPF doesn’t working. OSPF status is:Init
If i disabling one peer and for the second use allowed-ip 0.0.0.0/0 OSPF work excellent between Main router and one peer. OSPF status is: Full
Peers configuration: allowed IP 0.0.0.0/0.
If you need 0.0.0.0/0, then use two separate WG interfaces.
@anav: Where are multiple peers in your example? I see only router A and B, so each will have only one peer - the other router. No?
TAKE TWO…
Too funny, thanks, I was assigning different subnets as peers and completely missed the boat. Now I am going to have to get on my jet ski and catch up to the boat.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
…
This is the problem. When having multiple peers on a single interface, wireguard uses the allowed-address setting to determine which peer the packet should be sent to. If the destination IP of the packet is in allowed addresses for the first peer, it will be sent to the first peer. If the destination IP is in the allowed addresses for the second peer, it will be sent to the second one. You have defined your allowed addresses as 0.0.0.0/0 which will match absolutely everything to both peers, but it would probably check the first peer first and then the second peer would never receive anything.
…
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I take issue with the above statement as I think he is mixing apples and oranges.
TRAFFIC OUTBOUND FROM ROUTER - thru tunnel
If the traffic is outbound from a router, the PEER, settings refer to the addresses that the router will look for match and select for entry into the tunnel.
Since traffic outbound 99% of the time refers to local subnets that use the tunnel to reach internet (or subnets) from the remote device.
Typically the allowed addresses used is 0.0.0.0/0 and these are the destination addresses the router will be matching and selecting to enter the tunnel.
I dont see how there is going to be any conflict or errors here.
Any other device external to the local Router will have a different wireguard interface and likely have opposite flow, like an iphone coming into the router via the tunnel.
Therefore I do not see how it is possible to have two different peers heading towards the tunnel FROM THE SAME DEVICE.
So the first step is proving to me that this event or scenario can even exist!!
Second steps is showing me the so what. If traffic from any source get sent through the tunnel, and is expected on the other end of the tunnel, it will be allowed to exit the tunnel etc… No harm no foul, and no problem,
TRAFFIC INBOUND TO ROUTER - thru tunnel
If the traffic is inbound to a router, the PEER, settings refer to the addresses that are filtered, (not selected) and thus allowed to exit the tunnel and be firewalled to either the WAN or LAN as applicable. Again, I dont see how there is going to be any conflict or errors here.
Imagine that you have heavily censored internet, where ISP blocks access to your favourite websites. But you also have some remote server, perhaps some VPS you buy, or friend’s router, anything, so you create WG tunnel from your router to this server, and use it to browse internet. It’s simple allowed-address=0.0.0.0/0 on your end, default route to tunnel, and good bye censorship. But it’s not reliable, so you get another one, which is also not reliable (because ISP is trying really hard to block you). But from the two, at least one always works, so the solution is to create sort of dual WAN made of WG tunnels. And here comes the problem.
If you’d use single WG interface, you’d have two peers and both would have allowed-address=0.0.0.0/0. So if you want to send packet to 1.1.1.1, where should it go, to which peer? To one of them for sure, but you can’t control to which one. It’s not really a problem, because you can simply use separate WG interface for each peer. And with this example it’s pretty clear from the start that it’s nonsense. But if you take WG as regular interface and forget about its internal magic, it’s possible to get confused.
For example, let’s say you have remote site with 192.168.88.0/24 LAN and two WANs. You want a tunnel from you to there, and you want two, one to each WAN, as backup.
/interface wireguard
add name=wg1 ...
/interface wireguard peers
add interface=wg1 allowed-address=10.0.0.2/32,192.168.88.0/24 endpoint-address=<remote1> comment="main"
add interface=wg1 allowed-address=10.0.0.3/32,192.168.88.0/24 endpoint-address=<remote2> comment="backup"
/ip address
add interface=wg1 address=10.0.0.1/24
/ip route
add dst-address=192.168.88.0/24 gateway=10.0.0.2 distance=1 check-gateway=ping
add dst-address=192.168.88.0/24 gateway=10.0.0.3 distance=2
At first sight it looks fine, right? That’s how you’d do it with ethernet, it would be perfectly valid and functional config. You have two gateways (10.0.0.2 and 10.0.0.3) and standard failover config for routes. If everything is ok, traffic to 192.168.88.0/24 will be routed via 10.0.0.2, and when main tunnel fails (10.0.0.2 won’t be reachable), it will switch to 10.0.0.3. But it won’t work, because if WG interface gets packet for 192.168.88.100, where should it send to, or ? It doesn’t know, because it doesn’t know anything about the business with routes, it’s on completely different level. It sees two peers, and 192.168.88.100 can go to both of them, so it can just toss a coin (it doesn’t really do that 
).
Got it, so in that case the only real solution is to use a different wireguard interface altogether.
Aside from some crazy hack (*), yes.
(*) You could start without 192.168.88.0/24 in allowed-address, use netwatch to monitor 10.0.0.2 and 10.0.0.3, and add 192.168.88.0/24 to right peer based on that. But don’t do it for real. 
I want to understand first: why OSPF doesn’t work if allowed-address not 0.0.0.0/0 on main router? Ping from main router and client works good, I can enable EOIP tunnel on this wireguard tunnel, and it also works goid, it mean network connectivity is ok. But OSPF is :init.
I don’t want to use two wireguard interface, because I need two ports for each one. And it isn’t perfect solution.
I don’t know enough about OSPF, if it perhaps has any extra requirements. But just WG simply can’t have same allowed-address for more than one peer. Try to think about it, you have:
- peer1 with allowed-address=0.0.0.0/0
- peer2 with allowed-address=0.0.0.0/0
Then you want to send packet to 1.2.3.4, how would you decide to which peer it should go? You can’t.
I know this topic is already old but let me explain.
According to introduction of OSPF on Wikipedia, OSPF using multicast packet to negotiate each other, and make sure the neighbor still alive or not.
It uses 224.0.0.5 as multicast IP to send packet when in broadcast and ptp network type (may also use 224.0.0.6 in broadcast type).
Based on this, you also need to set 224.0.0.0/24 in WireGuard peer allowed address so that WireGuard won’t block OSPF connection.
BTW, you may also need to set LAN subnets from target peer site, or WireGuard would also block a packet that target to it.
But even that, you still need create another WireGuard interface if you have multiple sites need to organize with OSPF.
Means you need to add new WireGuard interface for each site. Because all OSPF neighbors using 224.0.0.5 to negotiate, and would met same situation like what #6 talked about.
You can set one site and multiple clients (PC, smartphone) on a same WireGuard interface at least.