HAPAC CLIENT
/interface list members
add interface=wifi1 list=WAN
add interface=bridge1 list=LAN
ip firewall nat
add action=masquerade chain=src-nat out-interface-list=WAN
MAIN ISSUE
/routing rule
add action=lookup-only-in-table disabled=no src-address=192.168.100**.254/32**
table=useWG
Change to
/routing rule
add action=lookup-only-in-table disabled=no src-address=192.168.100.0/24
table=useWG
I’m assuming there are no firewall rules because you are behind another router that contains firewall rules??
SERVER ROUTER
PROBLEM #1
You have local pool with the same IP address. Its actually worse see below, its a pool to a wg interface which only gets an IP address!!!
There are three solutions that I see possible.
a. the easiest fix is to add this source nat rule to the client router and what this will do is give all traffic leaving the client router and arriving at the server router the allowed IP of 10.20.30.3
and thus there will be no conflict at the Server end.
add action=masquerade action=srcnat out-interface=WG-C
NOTE This can also be accomplished if you simply add the WG-C interface as a member of the WAN list and since the list is already used in the existing source nat rule, it does the same thing.
Either way, it solves the problem.
/interface list members
add interface=wifi1 list=WAN
add interface=WG-C list=WAN
add interface=bridge1 list=LAN
b. Change the subnet to something NOT on the server router and then you will need to ensure that allowed IPs and a route exist on the server router for for this non-conflicting subnet. This is the one I recommend and after looking at server config the MUCH PREFERRED option, to make life Less complicated when looking at all your routers!!
PROBLEM #2 Maybe…
If you elect to change to a different subnet on the Client router to avoid conflic then it needs to be reflected on allowed IPs and ip routes on server router.
add allowed-address=10.20.30.3/32,(NEWSUBNET).0/24 comment=WG-Warrior interface=WG-Ongar
public-key=“=”
/ip route
add dst-address=(newsubnet).0/24 gateway=WG-Ongar routing-table=main
PROBLEM #3
One has to ensure that either the Client WG IP address if using sourcenat to deconflict, or the newsubnet address to deconflict, is allowed in the forward chain firewall rules to reach the WAN of the Server Router!!
As an aside: I hope you see now how this rule is confusing. You have the same subnet coming from the MT client router and a very good additional reason to change the local subnet at the MT Client Router. Also, what is the point of allowing the entire source address to be able to config the router???
/ip firewall filter
add action=accept chain=input dst-port=13231 protocol=udp
add action=accept chain=input dst-port=8090 protocol=udp
add action=accept chain=input comment=Wireguard src-address=192.168.100.0/24
+++++++++++++++++++++++++++++++++++++
I dont quite see the purpose of this rule… ??? It seems to allow all users access to config wireguard even if they didnt get there from wireguard and it will only work for the pc peer of 10.20.30.2. and not the mt client.
add action=accept chain=input comment=Wireguard src-address=10.20.30.0/24
Better is:
add action=accept chain=input comment=Wireguard in-interface=“WG-Site A” src-address-list=Admin
(where I would put any local admin IPs from MT client router and the separate 10.20.30.2/32 for the pc on the list)
+++++++++++++++++
OTHER MISC ERRORS
why duplicate pools
add name=dhcp_pool3 ranges=192.168.100.2-192.168.100.254
add name=dhcp_pool4 ranges=192.168.100.2-192.168.100.254
add name=dhcp ranges=192.168.88.2-192.168.88.254
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
WHY are some peers not X/32 ??
They should all be X/32 unless the MT server is actually a client for some other WG server ( and since you dont have persistent keep alives either, its clear they should all be X/32 )
Why are you adding subnet attributes to WIREGUARD Interfaces !! Wrong Wrong Wrong.
they only get IP address!!!
EGADS you also messed up peers.
add allowed-address=10.20.30.2/32 comment=“Lenovo PC” interface=“WG-Site A”
public-key=“vkSOK5NxWc+E4Dmhne4nyMnIAz3LwxbI9KSg3L2Yg0Y=”
add allowed-address=10.20.30.3/32 comment=WG-Warrior interface=WG-Ongar
public-key=“fGm6nL35r9Vc83yA49SSzuQiY5mYRfyXS59WYZmTE3k=”
should be
“WG-Site A”
YOUR FIREWALL RULES ARE PURE JUNK and not in any functional practical order…so messy you cannot even see the issues…
for example you have DNS open to the internet LOL, for all those useless port knocking and other rules ( the router can never stop ddoss etcc), you leave yourself wide open to abuse.
Thus unable to address firewall rules pertaining to wireguard traffic as you have no control over anything at this point.
