(1) I prefer vlans to bridges, but everyone has their own fetish.
(2) Where is the pool, dhcp server, for bridge IOT, I only see it included in IP address and dhcp-server network???
(3) Where is interfaces WG-Client-Hassio Defined???
It has to come from somewhere and cannot just be added to interface lists without actually existing??
(4) Remember the purpose of interface lists is to normally simplify the firewall rules such that
a. two or more whole subnets can be described by an interface list
b. an exception is usually just the management interface when used.
c. address lists are better for less than whole subnets ( a subset of IP addresses, within or accross subnets), or with a mix of users described by both subnets and subsets of IP addresses).
d. Single subnets are best decribed by the interface its on, such as vlanX or ether3, or by dst or src address=subnet.
Not sure what you are doing but it feels overly complex and messy than what is required.
(5) Overall I think you are being too cute with sourcenat rules but I am not expert so will ask the questions…
a. What is the purpose of this source nat rule which contains both the same src address and dst address? Hairpin nat?
add action=masquerade chain=srcnat comment=“defconf: masquerade” dst-address=
!192.168.0.0/16 ipsec-policy=out,none out-interface-list=WAN src-address=
192.168.0.0/16
b. What is the purpose of this rule…
add action=masquerade chain=srcnat dst-address=!10.20.60.0/24 ipsec-policy=
out,none out-interface-list=WAN src-address=10.20.60.0/24
Do you want all the incoming remote wireguard users coming into the router to go out your internet natted with the IP of your WAN?
There are a number of ways to accomplish this.
One is to include the interface as part of the WAN list
add interface=WG-Server list=WAN
However why would you want to do this? The router is aware of the clients within it that you have identified. Considering the single clients have an IP address of 10.20.60.X
The router already has a route back to the tunnel.
Where making additional route rules comes into play is if you have subnets coming into the router lets say from a remote MT Router device with client subnets, well they are identified on the local router peer lists.
So its real simple to simply put
add dst-address=remotesubnet (.0/24) gwy=WG-Server server table=main DONE.
Any return traffic from the internet or local subnets will get routed appropriately.
In addition you already added the WG Server interface to the LAN list where it makes more sense with firewall rules.
(6) This naturally falls out in a conversation about the next rule.
Here you want to ensure that users from the local bridge going out the wg tunnel are given a source IP address (natted) to that of the wireguard and not the actual subnet source addresses.
For various reasons… like going to third party VPN etc…
So this makes more sense to me. EXCEPT it looks like the format is wrong!!
add action=masquerade chain=srcnat comment=“masquarade vpn”
out-interface-list=VPN to-addresses=10.7.0.4
This should be better
add action=src-nat chain=srcnat dst-address=10.7.0.4 in-interface=brg-local
Thus any traffic heading out the wireguard interface from local users will get the IP address 10.7.0.4 as source address.
******************** The assumption here is that you want to send all local bridge users out the wireguard for internet ???
(7) I cannot comment on routes until assumptions are cleared up on user requirements.
For all I know you want remote users coming in on WG-Server to go out WG-Client tunnel not local users.
The better you state the requirements, the better the config will be!!
(8) Same goes for your mangling.
