KMT
(1) since you have 0.0.0.0/0 entered as an
allowed IP, there is no need to enter any others, they are all included.
(2) Wireguard is a UDP protocol and thus one of your input rules is not required (should be removed).
add action=accept chain=input dst-port=13231 protocol
=tcp
add action=accept chain=input dst-port=13231 protocol=udp
(3) Firewall rules and organization are lacking, the defaults are excellent with minor tweaking.
/ip firewall filter
{Input Chain}
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input dst-port=13231 protocol=udp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else
{forward chain}
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=accept chain=forward comment="allow local subnet to enter wg tunnel \
src-address=10.7.7.0/24 out-interface=wireguard1
add action=accept chain=forward comment="allow remote subnet to exit tunnel \
in-interface=wireguard1 dst-address=10.7.7.0/24 src-address=10.8.8.0/24
add action=drop chain=forward
NOTE: I tend to use the firewall rules to allow subnets to enter the tunnel and use firewall rules (at the other end, the receiving end) to be more explicit on where traffic exiting the tunnel is allowed to go! Hence the difference in the two rules above. The first one basically says yeah traffic from the subnet is allowed to enter the tunnel, especially practical if going out the remote site for internet. However if traffic is coming out of the tunnel, I want to ensure I configure at least the destination and the source is essential if you have multiple subnets possible..........
(5) Mangling is not required and remove (and thus fastrack is now part of forward chain rules)
(6) Missing but not totally necessary is interface and interface lists........ they are very handy to work with subnets. I prefer them over firewall address lists. One reason to use firewall address lists is if you have less than a subnet, like a single or group of IPs or a mix of subnets and a single, or group of IPs. The IPs could be from different subnets for example.
It may not be 100 percent necessary now but could be really useful down the line.
Thus suggesting add in
/interface list
add name=WAN
add name=LAN
/interface list members
add interface=ether1 list=WAN
add interface=LAN-Right-Half list=LAN
PS, this will work in the firewall chain as the LAN will have access to the router for DNS and NTP services.
If you want to maintain the separate rules for dns and ntp you can always do this.
add action=accept chain=input in-interface-list=LAN src-address-list=Admin dst-port=xxxxxx,yyyyyy protocol=tcp {winbox port
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \ {and NTP *** services if required etc}
dst-port=53,123 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="drop all else"
where src-address-list is a firewall address list of admin device or EVEN external IPs coming in from the internet.
For example on my own source address list, I have the wireguard IP I set to my iphone, so that I can wireguard into my router and then access the config.
(7) In terms of routing your LAN traffic, you do realize that we are moving all your subnet traffic out the wireguard tunnel and thus the routing would look like in basic terms.
add dst-address=0.0.0.0/0 gateway=ISPgateway table=main
add dst-address=0.0.0.0/0 gateway=wireguard1 table=via-wg
You already have the table built, now for the routing rule which will ensure all users go into the wireguard tunnel.
/routing rule add src-address=10.7.7.0/24 action=lookup-only-in-table table=via-wg
note: if you still wanted the users to be able to access the local WANIP if the wireguard tunnel was not working, then simpy change the action to:
action=lookup
+++++++++++++++++++++++++++++
Where this gets tricky is later you have another local subnet and you want users to be able to access the other subnets.
In this case we add additional route rules prior to the internet one and there are multiple ways to achieve these sort of goals but the easiest is (and order counts)
/routing rule add
dst-address=subnetB table=main
/routing rule add src-address=10.7.7.0/24 action=lookup-only-in-table table=via-wg
Here, the router will ensure that traffic from the subnet using internet (subnetA) to subnet B will take precedence.
(8) Looking at your routes, a bit of tweaking required, ..........
Get rid of distance between the routes you need they should all be set to default of 1.
The first wireguard one, ensures that any incoming remote subnet traffic has a path back to the tunnel after interacting with the local subnets.
The second wireguard route creates a route for all traffic originating on the local router to go out the tunnel and puts it in the via-wg table.
(the route rule then 'forces' the local subnet to that table and thus route).