Wireguard - Client disconnects when new client connects

RouterOS General
1

Hi all,

I’ve been driven crazy by this issue all day. I’ve read the documentation and I’ve read @anav’s excellent Wireguard Success For The Beginner guide and I stil think my configuration should work but it doesn’t.

I have a CHR as a Wireguard server. I have three other CHRs that I want to connect to it. However only one peer at a time seems to be able to connect. If I disable and enable wireguard on another peer it will disconnect the one that’s just been connected.

Essentially I’m attempting a “Road Warrior” scenario with the peers. And even in a lab I’m running into the same issue. The config snippets below are from my lab setup. No firewall configured. No NAT and no fasttrack.

No duplicate MAC addresses, no duplicate IP addresses and all public keys are correct.

I’ve probably spent too long at this now to see some obvious mistake so I’m hoping some fresh eyes and someone with greater knowledge might see something i’m doing wrong.

EDIT - By client disconnecting I mean that if one peer is connected and can ping the wireguard server on 10.1.1.1 The next that connects will result in the ping failing and then only the newly connected peer can ping 10.1.1.1

First is the config of the Wireguard Server:


/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=192.168.200.103 interface=wireguard1 public-key="+qbs4wLvSw6GR3eMkwBRR1ymFYNyNW+uWvnTToGSMEc="
add allowed-address=0.0.0.0/0 endpoint-address=192.168.200.104 interface=wireguard1 public-key="qXXSsBjIaldjVebVwIeZc0qHj6QXeCy9gDZcigTH6wE="
add allowed-address=0.0.0.0/0 endpoint-address=192.168.200.102 interface=wireguard1 public-key="ADSn6CBML7s8JiE99mPG0mqzXjLKohD7cBIik8MG4SQ="




/ip address
add address=192.168.200.101/24 interface=ether1 network=192.168.200.0
add address=10.1.1.1/24 interface=wireguard1 network=10.1.1.0




/ip route
add dst-address=0.0.0.0/0 gateway=192.168.200.1




/routing/route> print
Flags: A - ACTIVE; c, s, a - SLAAC; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
    DST-ADDRESS           GATEWAY        AFI   DISTANCE  SCOPE  TARGET-SCOPE  IMMEDIATE-GW
As  0.0.0.0/0             192.168.200.1  ip4          1     30            10  192.168.200.1%ether1
Ac  10.1.1.0/24           wireguard1     ip4          0     10                wireguard1
Ac  192.168.200.0/24      ether1         ip4          0     10                ether1
Ac  fe80::%ether1/64      ether1         ip6          0     10                ether1
Ac  fe80::%wireguard1/64  wireguard1     ip6          0     10                wireguard1
A H ether1                               link         0

Each peer has an almost identical config so I’ll just post the config of one:


/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=192.168.200.101 endpoint-port=13231 interface=wireguard1 public-key="Y/Whx13s4517zbRgmI7vGI0o7EeVUiFQgddTnBeMh30="




/ip address
add address=192.168.200.102/24 interface=ether1 network=192.168.200.0
add address=10.1.1.2 interface=wireguard1 network=10.1.1.2




/ip route
add dst-address=0.0.0.0/0 gateway=192.168.200.1
add disabled=no dst-address=10.1.1.0/24 gateway=wireguard1 routing-table=main suppress-hw-offload=no
2

On the peers on server side, you do not want to put 0.0.0.0/0 as allowed addresses.
Only the peer IP will do. /32-format.
If there is a subnet behind that peer which needs to be reached (and which is not already present elsewhere), you could add that as well.

As it is now there is huge overlap.
And then Wireguard will not know where to go to.

Look at it from this way:
Assume you ping from peer to server.
On the peer on your road warrior device, you specify allowed address 0.0.0.0/0, everything is allowed to enter the tunnel.
On the peer on server side, if you only specify the peer IP, WG will know the response needs to go to that peer, and no other.
If you specify 0.0.0.0/0 on server side, WG has no unique way of determining what peer the traffic needs to be send back to.
All are allowed.

So I “think” you did not follow the guide closely enough :laughing:

Important Discussion of > Allowed IPs
Think of ‘Allowed IPs’, in the sense of IP addresses being identified on the OTHER END DEVICE, when identifying the TWO local distinct traffic flows of INBOUND and OUTBOUND. > Plus we normally add the wireguard interface IP addresses of all peers that may be used for pinging and troubleshooting connectivity.

3

YES!!!

Thank you!

I knew it had to be something relatively simple. I indeed missed that bit in all my reading earlier.

Adding the following on the server site worked absolutely perfectly!

Also I think this is the quickest I’ve seen a question resolved ever on the forum.

/interface wireguard peers
add allowed-address=10.1.1.3/32 endpoint-address=192.168.200.103 interface=wireguard1 public-key="+qbs4wLvSw6GR3eMkwBRR1ymFYNyNW+uWvnTToGSMEc="
add allowed-address=10.1.1.4/32 endpoint-address=192.168.200.104 interface=wireguard1 public-key="qXXSsBjIaldjVebVwIeZc0qHj6QXeCy9gDZcigTH6wE="
add allowed-address=10.1.1.2/32 endpoint-address=192.168.200.102 interface=wireguard1 public-key="ADSn6CBML7s8JiE99mPG0mqzXjLKohD7cBIik8MG4SQ="
4

No prob.
Glad to have been of assistance.

5

I’m convinced you were totally drunk when reading the article…
The issue of peer settings and possible infractions is pointed out!!!
Go straight to jail!! :slight_smile:

A. OUTBOUND: In the case of outbound traffic from the local device to the remote device (From SOURCE) , the destination addresses are used by the local WG Device in a SELECTOR (matching) function, to be determine if any of the local users’ destination addresses, being executed at any time, line-up with those IP addresses identified on the one or more PEER settings on the local Wireguard settings. More specifically, the Device will first determine if a Route exists for that traffic(destination address) and then if the IP Route associated Gateway points to the Wireguard Interface, the Router will then check the Allowed Addresses, starting with the first Peer for that Wireguard interface and then any remaining peers. The Peer selected (first match) will determine the tunnel selected (destination IP and Port). A WG interface can have multiple peers and each peer can have multiple addresses. Be careful of overlapping or duplicating such Peer Allowed IPs/destination IP addresses as that will cause issues and is a CONFIG ERROR on your part. ( see - (2) )

FUN FACT: What you will discover with experience is that there is OFTEN duplication of inbound and outbound flows. Put simply, it is not uncommon for the destination IPs of local users (outbound) to be the same as the source address of inbound remote users (bidirectional traffic). Thus a single “Allowed IP” entry may cover both inbound and outbound traffic. The extreme case being Alllowed IPs=0.0.0.0/0 which allows all traffic (but in this case watch out for overlapping peers) <--------------- perhaps I should bold this one LOL


CAUTION OVERLAPPING PEERS CAUTION: One should not have the same IP addresses identified on two or more peers of ANY SINGLE Wiregard Interface. If you find yourself in this situation, create another WG interface to separate the duplication +++++.

Reason. The local WG device, as stated previously, when receiving a destination address from a user first locates a working route for that traffic and then attempts to match the destination address to the ALLOWED IPs lists entered into the peers of that particular interface (in our case a Wireguard interface), and if it finds a match, selects that peer and sends the traffic accordingly. It has no way of knowing which peer to send that traffic too and only matches the first available peer IP address. This issue is more frequently seen when sending out users through a remote site for internet and have several peers for this purpose, as both have the same destination address of 0.0.0.0/0. The peers do not need to be active for this error to be experienced.
++++ To create another wireguard interface you will need an additional listening port and associated input chain rule on the WG Remote (Server) Router.


PEER ALLOWED IPs In general, the Router acting as a hub (usually the receiver of initiated connections) will have specific Peer settings for each client. In this regard each peer in allowed IPs for the wireguard IP, should be set to the specific IP/32. When one has multiple routers, ensure that on any given router, there is not the case of overlap with two wgsubnet .0/24 settings to describe allowed IPs (no two peers on any router should have.0/24). The router will not know which peer you are discerning (much like overlapped peers discussed previously). It is okay to have a mix of one wgsubnet .0/24 and multiple specific wgips/32 as /32 is a longer mask (like in routes) and will always be chosen when requested and thus the router will not be confused at any point.
For single clients its normal/okay to put the wg subnet for allowed IPs.

(only considering Wireguard interface IP addresses, for actual traffic add to this base/minimum setting)
Iphone (Peer=Local Router), Allowed IPs=10.10.5.0/24 (done) [note: not required if for internet access as 0.0.0.0/0 includes all addresses.]
Laptop (Peer=Local Router), Allowed IPs=10.10.5.0/24 (done) [note: not required if for internet access as 0.0.0.0/0 includes all addresses.]
Hex (Peer=Local Router), Allowed IPs=10.10.5.0/24 + any other traffic required = outbound (remote destination addresses at local) + inbound (remote source addresses from local)
Local Router : SERVER FOR CONNECTIONS
Peer1 AllowedIPs=10.10.5.2/32 (done)
Peer2 AllowedIPs=10.10.5.3/32 (done)
Peer3 AllowedIPs=10.10.5.4/32 + any other traffic required = outbound (remote destination addresses at hex) + inbound (remote source addresses from hex)

IP ROUTES
Iphone & Laptop not applicable - Mobile Devices (dependent upon the particular architecture of smart phone OS or Laptop OS apps etc…) They can ping directly as the routing is applied internally.
Hex (created dynamically)
(dac) dst-address=10.10.10.0/24 gwy=wg-peer3 table=main (routes hex pings to Router (dest addr) and/or routes remote Router return traffic after pinging hex)
Local Router (created dynamically)
dst-address=10.10.10.0/24 gwy=wg-local table=main routes Router pings (dest addr) to all peer devices and routes remote Peer return traffic after pinging Router)

6

That is extremely helpful @anav.

Thanks for such a thorough reply!