I have searched and read through several different posts in this forum about the same issue, but none of them seem to apply in my case?

Background: Lightning took out my router, which I had a working wireguard config on, but (silly me!) I didn't have a recent backup of my config which included the wireguard config. So I have had to rebuild it from scratch. In other words. I'm reasonably confident this is something *I* have done wrong, and would love some help spotting it!

Currently, either peer will work, but whichever peer connects first is the ONLY peer that will ever work, until I disable/reenable one of the peers or otherwise make some config change. At that point, again, whichever peer connects first will work, any additional peers will show a successful handshake, but no additional traffic will pass.

At this point, I have stripped it down to two peers, a phone and a laptop. Full config can be posted if needed, but for now will stick to relevant pieces.
then Now peers (Full disclosure, there is a preshared key also. I have verified it is correct on all peers and in the mikrotik): And a print detail for the peers (redacted sensitive info): and Firewall: Route is in place: Based on other posts, I have tried seen the issues with endpointaddress="" listings in the config. As seen above the listing does not appear in an export, but does show when you do a print. If one of the peers is connected when you do the print, the peer's public IP is listed in that field. Once the peer is disconnected the print shows the empty field again, so I kind of have to assume this is the expected behavior.

As stated, If both peers are disconnected, I can just disable/reenable either of the peers, or make any other config change to either peer. And whichever peer connects first works, the other does not. I really need more than one per at a time connected though!

Thanks in advance for any and all advice!

On "server", the allowed addresses on client peers should not be /24 for the wireguard addresses.

On the server when the second client makes connection, server will not know which peer to choose.

/32 for wireguard addresses, /24 ( or whatever) for other allowed subnets.

That was exactly it! (And it makes sense, also!)
THANK YOU!

No problem.

Peer settings look wrong.
At the MT, being the server, the peers are simply /32 not/24

Oopsie already answered, opened it and then left for what I thought was a few minutes and then became hours LOL.

thank you, gents, that was exactly my problem as well and got resolved by changing /32 on the server

There is logic behind what has been suggested. Its just not a case of memorizing, its a case of understanding.

The Server client ( for handshake ) may have 2 or more peers connecting to it.
That is multiple peer to peer tunnels.

The way any local traffic heading outbound gets sent is by several factors.
a. first the router checks the destination address.
b. does the dst address match any allowed IPs in the wireguard allowed IP list and it SEQUENTIALLY from top to bottom reads the list.

- thus if you have entered a /24 address for wireguard of a peer, ANY destination for other peers .3, .4, .5 will get trapped and get sent out the wrong peer subtunnel so to speak.
- thus if you have entered 0.0.0.0/0 address for a wireguard peer, ANY destination (be it wireguard address, or subnet) will get trapped and get sent out this peer.

So the moral of the story, is understanding that the outbound heading traffic undergoes a MATCHING and filtering process.

c. Do firewall rules permit the flow of traffic from source to destination is another router process
d. Is there a route for the destination traffic, ( aka a remote subnet for example !! )

... /32 for wireguard addresses ...

For routed links work:

... /32 for wireguard addresses ...

For routed links work:

Code: Select all

# 2024-11-15 16:42:06 by RouterOS 7.12.1
#
/interface wireguard peers
add allowed-address[color=#008000][b]=10.254.10.34/32,0.0.0.0/0 ...
add allowed-address=10.254.10.35/32,0.0.0.0/0 ...[/b][/color]
#

There is no point in putting 0.0.0.0/0 and any other address as 0.0.0.0/0 = all possible addresses,
So its mildly amusing but wrong and if this is on a server router for handshake, a recipe for disaster
as traffic will NEVER make it to the second client on the list.