Diagram is excellent it was assumed the separate path to the wireguard server was simply to illustrate its transparent nature through the ISP router etc, once the connection was established.
(1) Minor - IP address needs fixing......... This may be purely cosmetic but its recommended on MT devices to provide the standard setup.
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
192.168.88.0
add address=10.66.66.8
/24 interface=wireguard1 network=10.66.66.0
(2) My biggest issue is the routing setup. Its very confusing as you have a private IP from the provider, Why do you have multiple table main routes for the provider??
Are we to assume its a fixed IP or not? In any case..............
Route-
1ISP = /ip dhcp-client add comment=defconf default-route-
distance=2 interface
=ether1
Route
-2ISP = add dst-address=0.0.0.0/0 gateway=192.168.2.1
Different distances too...... What are you trying to do give your router an ulcer?
If its a fixed IP, then remove the IP DHCP Client method, add the address of the router in IP address and keep the manual route you have.
/ip address
add address=192.168.2.23/24 interface=ether1 network=192.168.2.0
/ip route
dst-address=0.0.0.0/0 gateway=192.168.2.1
dst-address=0.0.0.0/0 gateway=wireguard1 table=useWG
/routing table add name=useWG fib
/routing rule add src-address=192.168.88.0/24 action=lookup-only-in-table table=useWG
Note: If you want users to be able to use local ISP if wireguard tunnel goes down then use action=LOOKUP.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
So in general one has to take care of
IP routes - DONE
Firewall rules - DONE ( your firewall rules do not block LAN to WG traffic )
WG settings - DONE
BUT SOMETHING IS NOT RIGHT STILL - Lets think about it, if you had read the reference, you would have picked up on this.
Answer the question ---------------------->
What IPs is the WG server expecting (based on its allowed IPs).
Correct answer --------------------------->
Yes, its expecting all traffic to be from
10.66.66.8/32
So for third party VPNs we also have to consider SOURCE NATTING the traffic entering the tunnel so that its accepted at the other end.
Thus add this sourcenat rule.10.66.66.8
add action=masquerade chain=srcnat out-interface=wireguard1
Note: You could also add the wireguard1 interface, to the INTERFACE LIST of WAN and this would have the same effect and would use the current default rule you have in place.
/interface list member
add interface=wireguard1 list=WAN