(1) Dont need keep alive setting on MT peers… since the clients initiate the tunnel the keep alive is valid for the clients.
(2) Your bridge setup is confusing… specifically
a. why is ether2 on the bridge when it has a separate IP address.
b. where is the IP address for the main bridge?
Okay looking at this maybe there is some reasoning…
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0 { this should be the address for the bridge not ether2 }
add address=192.168.80.1/24 disabled=yes interface=bridge-guest network=192.168.80.0 { okay disabled }
add address=192.168.100.1/24 comment=Wireguard interface=wg_MK network=192.168.100.0 {good}
/ip arp
add address=192.168.88.2 interface=bridge mac-address=EE:94:F6:E5:72:FA { Not sure what you are trying to do here }
(3) Seems a tad redundant. Since the subnet already describes the sum total of possible in-interface users, it is meaningless. It would be worthwhile to put a source address list for one or a source-address-list for some incoming wireguard users BUT NOT ALL of them. In this case, there is no intent or need to only allow some of the wireguard users…
add action=accept chain=input comment=“allow wireguard traffic” in-interface= wg_MK src-address=192.168.100.0/24
Thus could be … (nit picking)
add action=accept chain=input comment=“allow wireguard traffic” in-interface=wg_MK
(4) By the way, you already have access covered by other looesy gooesy input chain rules..
This rule would allow all wireguard users to access the input chain as you added the wireguard interface to the LAN interface list.
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN
The problem with this rule is that it also allows ALL LAN users potentially to config the router. Suggest the following…
add action=accept chain=input in-interface-list=LAN src-address-list=authorized.
where the authorized list includes admin desktop, admin laptop, admin ipad, admin iphone on reserved mac lease on 192.168.88.0/24
AND
where the authorized list includes 192.168.100.0/24
Therefore the input chain would look like…
/ip firewall filter
{default rules}
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
{user added rules}
add action=accept chain=input comment=“allow wireguard” dst-port=13231
protocol=udp
add action=accept chain=input in-interface-list=LAN src-address-list=authorized
add action=accept chain=input in-interface-list=LAN dst-port=53 protocol=tcp
add action=accept chain=input in-interface-list=LAN dst-port=53 protocol=udp
add action=drop chain=input comment=“drop all else” { Only do this after you confirm the authorized firewall list works }
- Similarly there is nothing blocking your wg access to the LAN, not sure why things are not working.
However I had to infer that from your loosey gooesy rule set. Everything is allowed except WAN basically…
Much prefer
{Default Rules}
up to invalid
{User Rules}
add action=accept chain=forward connection-nat-state=dstnat comment=“allow port forwarding”
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward in-interface=wg_MK dst-address=192.168.88.0/24
add action=drop chain=forward comment=“drop all else”
- Why do you think you would be able to access by domain name…
Even people I know who want their users to access the server not by local IP but by the Router IP (dyndns name) dont have issues…
Do you mean those are DYNDNS names?? Like the IP cloud name of the MT Router??
Domain name I dont think work over this type of VPN
In any case if its by DYDNS Type name, try putting this rule on the router…
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.0/24
add action=masquerade chain=srcnat out-interface=ether1
…
By domain name over wg, you many need a different type of VPN or zerotier type connectivity (which is more layer 2 type connectivity)
