So you want MT2 users to access M1 servers and M1 internet.
(1) In this case on MT2, the allowed IPs should consist solely of 0.0.0.0/0 as this is what is needed to cover off internet inquiries.
The neat thing is this also covers off any subnets at M1, and the wireguard IP address at M1.
(2) We still need the route that points users into wireguard for the remote subnet they will be visiting 192.168.1.0/24 on table main.
/ip route
add disabled=no distance=1 dst-address=192.168.1.0/24 gateway=wg1 pref-src=“”
routing-table=main scope=30 suppress-hw-offload=no target-scope=10
(3) Your firewall rules are backward.
From:
add action=accept chain=forward dst-address=192.168.7.0/24 out-interface=wg1
src-address=192.168.1.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 in-interface=wg1
src-address=192.168.7.0/24
TO:
add action=accept chain=forward dst-address=192.168.7.0/24 in-interface=wg1
src-address=192.168.1.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 out-interface=wg1
src-address=192.168.7.0/24
Think of it this way. In the first rule you are saying traffic heading to the local subnet its coming in on wireguard1 and specifically from the remote subnet.
The second rule you are saying any traffic heading for the remote subnet from local users it going out the wireguard interface.
(4) Whats missing is the firewall rule for internet access, or more clearly stated, the ability for your local subnet users on M2, to enter the wireguard when attempting to either go out the internet via M1 WAN, or to m1 subnets, so we can basically replace the second rule above with one that covers off any traffic from local users on M2 to M1
so the two rules will now look like this
add action=accept chain=forward dst-address=192.168.7.0/24 in-interface=wg1
src-address=192.168.1.0/24
add action=accept chain=forward out-interface=wg1 src-address=192.168.7.0/24
(5) Now a new route required to ensure M2 users going out for internet get routed to the wireguard tunnel and we do this by forcing the users out the wireguard tunnel for internet instead of the local M2 WAN.
We need three things, the table, you already have, the routing rule and the route.
a. /routing table
add disabled=no fib name=tablWG
b. /routing rule add src-address=192.168.7.0/24 action=lookup table=tablWG
Note: If you want users to be able to access the local WAN if the wireguard tunnel goes down, then keep the action as noted above. However if you dont want them having any internet when wireguard goes down then change the action to: lookup-only-in-table
c. /ip route
add dst-address=0.0.0.0/0 gwy=wireguard1 table=tablWG
that should suffice for M2
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
M1 Comments…
(6) The masquerade rule for remote users coming out the tunnel (from mT2 or any remote user) and going out the WAN of the MT1 is NOT REQUIRED!
THe MT1 router has a direct link to the internet and thus returning traffic will be sent back to the KNOWN originators.
A. because the wireguard interface is on MT1
B. because one has a route through the wireguard interface for remote subnets
c. because one has firewall rules permitting the traffic flow.
Remove this rule.
add action=masquerade chain=srcnat comment=“niepewne dla lWireGuard”
disabled=yes out-interface=ether1 src-address=172.16.10.0/24
(7) I dont see an explicit firewall rule allowing mt2 users to go out WAN on MT1 so suggest adding it.
add chain=forward action=accept in-interface=wireguard1 src-address=192.168.7.0/24 out-interface=ether1
(8) I do not understand the purpose of this route assuming you made it?
add disabled=no dst-address=192.168.1.0/0 gateway=“public IP MT1”
routing-table=main suppress-hw-offload=no
If you dont know why suggest remove it.
