Wireguard Troubleshooting.

Hi.
I have a quite complex implementation of Wireguard and I could really use your help.
I have three different mikrotiks on different isp’s.

First site ( let’s call it wireguard server).
Mikrotik Natted, behind ISP router, wan IP of mikrotik is 192.168.1.2. port 13231 is forwarded from ISP router to 192.168.1.2
Mikrotik is wireguard server it listens to above port and has three peers.
Lan is 192.168.88.0 and mikrotik has 192.168.88.1 and 10.0.0.1 for wireguard

Second site
Mikrotik as Pppoe , so it’s the main router
Lan is 192.168.200.0 and router is 192.168.200.1 and 10.0.0.3 for wireguard

Third site mikrotik also Pppoe .
Lan is 192.168.188.0 . Mikrotik has IP of 192.168.188.1 and 10.0.0.4 for wg.

I can ping and coonect to everyone from everywhere. So it’s working fine. The problem is that I want one Rpi from first site who’s ip is 192.168.88.12 to connect to internet through ISP of site 2.
Also another PC with IP 192.168.88.13 from first site to have internet from site 3.
Is that possible? Or am I wasting my time?

Thank you for your time

VERY GOOD QUESTION.
On the face of it, it looks very much to be a situation of overlapping peers that even if you directed those two users to the wireguard interface via diff table then main, with associated route and route rules, the router would probably select the first peer on the list every time and thus would not solve the issue.
The simplest solution is to create a second wireguard interface for the second user to site 3 for example to avoid such issues.
I am exploring other avenues to see what could be done…

What I would normally have done, in the past, without being aware of the overlapping peers issue, which reflects how cryptokey routing works. I would have provided this
dst-address=0.0.0.0/0 gwy=wireguard-name table=UseWG
dst-address=0.0.0.0/0 gwy=wireguard-name table=UseWG

ip route rule src-address=user1-IP action=lookup-only-in-table table=UseWG
ip route rule scr-address=user2-IP action=lookup-only-in-table table=UseWG

However as stated the router would simply run through the list of WG peers and find the first match that worked and thus never reach the second peer for all such traffic. Not good!!

+++++++++++++++++++++++++++++++++++++++++++

Instead of creating another wireguard tunnel setup perhaps this is possible
dst-address=0.0.0.0/0 gwy=10.0.0**.2** table=UseWG-site2
dst-address=0.0.0.0/0 gwy=10.0.0**.3** table=UseWG-site3

ip route rule src-address=user1-IP action=lookup-only-in-table table=UseWG-site2
ip route rule scr-address=user2-IP action=lookup-only-in-table table=UseWG-site3

However I am not convinced yet, that this will work as the router may still simply ignore the gateway route address when doing the cryptokey process and the router may simply do the same as before and just start from top to bottom looking at all the peers for a match…

+++++++++++++++++++++++++++++++++++++++++++++

Summary, creating another tunnel is the quickest most direct solution… that I am aware of. ( will need to forward a second port at site 1, etc etc.)

Perhaps Sob will chime in, if he has an answer to the second proposal…since I am no expert on the uses of Wireguard interface addresses LOL.
This is a nuance beyond me… but my instinct says that the router will not care a wit about the wireguard gateway IP in the route, when it comes to matching an outgoing IP address to a list of peers…
Confirmed by a little birdie… There is no magical connection between IP Route and route marks etc and Crypto key Routing… no vulcan mind meld!!!

YOU NEED A SECOND WIREGUARD INTERFACE!!

Thank you very much for your detailed answer.
Now i have to test it , but it will take some time, because i dont want to start driving to remote sites which are pretty far , if i mess everything up/. let;s see if i can make a script to auto load default configuration if something bad happens…
Thanks again.

Just make another separate wireguard interface on Site 1.
At site 3 if you dont need any other traffic back or forth just remove it completely from the original/current wireguard interface as you will be able to do everything you need through the new tunnel.

at site 1
/ip address
add address=10.0.2.0.1/24 interface=wireguard2

at remote site 3
/ip address
add address=10.0.2.0.3/24 interface=wireguard

etc…