Dual WAN, same Gateway, no need for load balancing or failover, just specify which vlans use which wan port

Going back to first principles… Dont mix apples and oranges, when you vlans, do all vlans, no bridge dhcp etc.
As per the article → http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
ADD:
/interface vlan
add comment=HoM interface=BR1 name=VL10-HoM vlan-id=10
/interface list members
add interface=VL10-HoM list=LAN

[Ip pool and dhcp-server network need not change]
/ip address
add address=10.10.0.1/24 interface=VL10-Hom network=10.10.0.0
/ip dhcp-server
UNABLE due to some errors on the config…

  1. There is no reference to the LAN subnet attributed to the bridge on the dhcp-server… The closest seems to be this…
    add address-pool=VL100-POOL comment=“10.10.0.0 - Moved to Bridge to keep UNIFI
    _Controller, APs and Swittches happy” interface=BR1 lease-time=1d name=
    LAN-DHCP

But you already have an address pool for the LAN entity??
add comment=LAN name=LAN-POOL ranges=10.0.0.100-10.0.0.254

BUT, there is no vlan100 interface that I can see on your interface vlan list ??

  1. Looking at the vlan interface list you have created 6 VLANS but you have 9 pools ( 10 but not counting ether5 pool which you actually dont need if its just emerg access anyway )
    The xtra pools are
    VL100 (INFRA) for the non–existant vlan (replacing LAN pool ?)
    VL1010 (MGMT) again for a non-existant vlan

  2. Your /interface bridge ports, reference vlan1000, a non-existing vlan ???

  3. Your /interface bridge vlans, reference vlan100, a non-existant vlan??

  4. Typically for future work the neighbours discovery is aimed at the trusted subnet or subnets, which is/are usually assigned to a management interface.
    Thus the interface identified here is usually more narrow in scope for a more refined/complex config. The key being all smart devices being managed, should get their IP address from a trusted subnet.

  5. SECURITY ISSUE —> one should never provide direct external access to configuration ports… asking to get hacked. Also source port makes no sense.
    /add action=accept chain=input comment=“Allow Winbox & SSH” dst-port=8291,22
    protocol=tcp src-port=8291,22

If needing external access the router one should VPN in to the router and then access the config from the internal side.
Thus the rule should have something to prevent external access:

add action=accept chain=input comment=“Allow Winbox & SSH” dst-port=8291,22
protocol=tcp source address-list=AUTHORIZED
or at least in-interface-list=MANAGEMENT ( where admin accesses from trusted subnets ).

Personally I would change from default ports be it wireguard or winbox!!!
So the firewall address rule would look something like:

/ip firewall address-list { from static dhcp leases }
add address=admin1-IP list=Authorized comment=admin desktop local (work subnet)
add address=admin2-IP list=Authorized comment=admin laptop local
add address=admin3-IP list=Authorized comment=admin desktop/laptop local (mngmt network)
add address=admin4-IP list=Authorized comment=admin ipad/smarthphone
add address=10.1.1.5 list=Authorized comment=admin ether5 access

Suffice to say, I was unable to get to the DNS questions, as other issues need to be resolved first, but in that vein, can you explain what you are doing in DNS?
It seems you have two local IPs for DNS, please explain.
10.10.0.5
10.10.0.7

Your forward chain firewalls have become messy with needless duplications and you are missing THREE DEFAULT RULES>.
The rule in red, is open ended ( not a good security practice in general ) and should be removed to clarify requirements…
add action=accept chain=forward comment=“Allow IPSec policy - IN”
ipsec-policy=in,ipsec
add action=accept chain=forward comment=“Allow IPSec policy - OUT”
ipsec-policy=out,ipsec
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 - VLAN inter-VLAN routing”
connection-state=new in-interface-list=LAN
add action=accept chain=forward comment=“Accept all that is DST NATed”
connection-nat-state=dstnat connection-state=new
add action=drop chain=forward comment=“DROP - All from WAN not DSTNATed”
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

add action=drop chain=forward comment=DROP

Suggesting the following:
{ Default Rules }
add action=accept chain=forward comment=“defconf: accept in ipsec policy”
ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy”
ipsec-policy=out,ipsec
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

{Admin Rules}
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 LAN to user DNS" in-interface-list=LAN dst-address-list=DNS-Local
add action=drop chain=forward comment=“Drop all else”
/ip firewall address-list
add address=10.10.0.5/32 list=DNS-Local
add address=10.10.0.7/32 list=DNS-Local

The local dns servers still need to use the Router DNS service/cache etc… aka a path to get to the net.

Thus I would change the following as well to:
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.4.4
as you already have pointed the users in DHCP server-settings to go to the PI address,
This setting allows the other users/subnets as well as pi server go out to the net directly.

The input chain rules for DNS are good.

Thanks for the detailed response anav. Let me go and clean some of that up before reposting the config. While I had tried to clean out whatever entries I was using to try different things, there’s no doubt I missed a few.

A couple of points to answer your questions:

LAN & VLANs. Yes, I know good practice is to have only VLANs and not mix with a basic LAN/Subnet. I did try that but I was having trouble keeping my Unifi switches and APs happy when I used VLANs only. They need to talk to the controller and each other on an untagged / VLAN ID 1. In the end the only way I achieved that was by having a default LAN (10.10.0.x) subnet. It’s working so it’s not a high priority for me to reconfigure unless it’s causing other issues. The confusion between VL100 references and LAN are remnants of trying to get the Unifi kit working on a VLAN. I’ll clean that up.

I run two DNS servers at home, 10.10.0.5 and 10.10.0.7. These are AdGuard Home DNS servers though migrating them to Technitium DNS is being considered. Ideally all my devices will use these two DNS servers. They are working fine for everything going in and out of wan1 for now.

Again, thanks for the detailed review. I’ll start work on that now.