Comments:
(1) Missing entry, once all is complete.
/interface bridge
add admin-mac= auto-mac=no comment=defconf name=bridge vlan-filtering=yes
(2) Assign vlans to the bridge…
/interface vlan
add interface**=bridge** name=PC_LAN vlan-id=10
add interface=bridge name=Print_LAN vlan-id=30
add interface=bridge name=Server_LAN vlan-id=5
add interface**=bridge** name=VOIP_LAN vlan-id=20
(3) Why does the Server vlan “5” not have any other definitions.
(4) Get rid of the apples and oranges, if you want a subnet use a vlan.
Thus bridge subnet, should be changed to a vlan
/interface vlan
add interface**=bridge** name=88_LAN vlan-id=88
(5) Where is IP pool, DHCP server, DHCP server network for Server_LAN ??
(6) Clean up Bridge port settings… now having ether2 ( or LAN-PORT) on bridge makes more sense,…
/interface bridge port
add bridge=bridge comment=defconf interface=LAN_Port ingress-filtering=yes frame-type=admit-only-vlan-tagged
add bridge=bridge comment=defconf interface=ether3 pvid=88 ingress-filtering=yes frame-type=admit-priority-and-untagged
add bridge=bridge comment=defconf interface=ether4 pvid=88 ingress-filtering=yes frame-type=admit-priority-and-untagged
add bridge=bridge comment=defconf interface=ether5 pvid=88 ingress-filtering=yes frame-type=admit-priority-and-untagged
(7) This should be set to the management INTERFACE LIST or in other words, the one time a single SUBNET is identified as and interface list entry - which all your managed devices get their IP address from!!!
/ip neighbor discovery-settings
set discover-interface-list=Manage
Where
/interface list
add name=Manage
/interface list members
add interface=88_LAN list=Manage
OVERALL needs to change to this…
/interface list member
add interface=Server_LAN list=LAN
add interface=PC_LAN list=LAN
add interface=VOIP_LAN list=LAN
add interface=Print_LAN list=LAN
add interface=88_LAN list=LAN
add interface=88_LAN list=Manage
add comment=defconf interface=ether1 list=WAN
(8) This MISSING knowledge, your network diagram Failed to show me what IP address the switch has !!!
I will assume its the former bridge lanip structure so now our vlan88
Thus things get a tad complicated only because of unifi products.
Case A - unifi switch is like any other and thus its management vlan comes in tagged as per a proper TRUNK port. No change to bridge port settings required.
Case B - unifi switch expects the management vlan as untagged if so the Bridge ports above have to be modified as such to recognize that ether2 would have to be a HYBRID port.
/interface bridge port
add bridge=bridge comment=defconf interface=LAN_Port pvid=88
add bridge=bridge comment=defconf interface=ether3 pvid=88 ingress-filtering=yes frame-type=admit-priority-and-untagged
add bridge=bridge comment=defconf interface=ether4 pvid=88 ingress-filtering=yes frame-type=admit-priority-and-untagged
add bridge=bridge comment=defconf interface=ether5 pvid=88 ingress-filtering=yes frame-type=admit-priority-and-untagged
(9) MISSING, Bridge vlan interface settings to match
Case A (ether2 is trunk)
/interface bridge vlan
add bridge=bridge tagged=bridge,LAN_Port untagged=ether3,ether4,ether5 vlan-ids=88
add bridge=bridge tagged=bridge,LAN_Port vlan-ids=5
add bridge=bridge tagged=bridge,LAN_Port vlan-ids=10
add bridge=bridge tagged=bridge,LAN_Port vlan-ids=20
add bridge=bridge tagged=bridge,LAN_Port vlan-ids=30
Of course this could be shortened to
/interface bridge vlan
add bridge=bridge tagged=bridge,LAN_Port untagged=ether3,ether4,ether5 vlan-ids=88
add bridge=bridge tagged=bridge,LAN_Port vlan-ids=5,10,20,30
CASE B (ether2 is hybrid)
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=LAN_Port,ether3,ether4,ether5 vlan-ids=88
add bridge=bridge tagged=bridge,LAN_Port vlan-ids=5,10,20,30
(10) Dont know what you are doing here, but its not standard on a hex… suggest not using it.
/interface ethernet switch host
add mac-address=B8:CA:3A:91:3A:85 ports=LAN_Port share-vlan-learned=no
switch=switch1 vlan-id=0
(11) Modify IP address to match above and also missing definition of vlan5 here as well!
/ip address
add address=192.168.88.1/24 comment=defconf interface=88_LAN network=
192.168.88.0
(12) In terms of firewall rules. Input chain is SAFE but not optimal… It depends if you want access to the router to be minimized to just the admin or not.
Thats up to you to decide.
(13) For the forward chain
a. the order is out of whack. below is fixed!!
b. Also any mention of new etc… is redundant and not required / removed
This rule is now redundant and should have been removed…
add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new disabled=yes in-interface-list=WAN
/ip firewall filter
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,new
add action=accept chain=forward comment=
“defconf: accept established,related, untracked” connection-state=
established,related,new,untracked
add action=drop chain=forward comment=“defconf: drop invalid”
connection-state=invalid
++++++++++++++++++++++++++++++++++++++++++++++ above are basic default rules that should start the chain
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN { good! = to allow internet access by all LAN members}
+++++++++++++++++++++++++++++++++++++++++++++
Rest are partially okay but I see issues… one by one…
This is a better example of format but lets look at your logic…
add action=accept chain=forward dst-address=10.1.5.101 src-address=
192.168.88.0/24
add action=accept chain=forward dst-address=10.199.6.0/24 src-address=
192.168.88.0/24
add action=accept chain=forward dst-address=10.1.5.0/24 src-address=
192.168.88.0/24
First of all the last rule Already includes the first rule!!!
The second rule is weird, you are allowing access to your own router which is an input chain rule.
I will have to think about the validity of this second rule…
Something seriously wrong with these including OVERLAP anything with the 10.199.6.6
THE FORWARD CHAIN is NOT for PORT FORWARDING.
You have External IPs that are attempting access to the MT device…
The best solution is on the MAIN ROUTER to create routes that point to the subnets and associate them with the WANIP of the MT device as the solution.
Then these rules should make sense… as its more of a LAN to LAN type allowance…
Right now there is no way for the main router to reach the mT device if people are looking for 192.168.88.0 its traffic the main router will just drop.
Example of this type of rule…
add action=accept chain=forward dst-address=192.168.88.0/24 out-interface-list=LAN
src-address=10.199.6.6
I will have to think about this as well. 
Overall, I would try to simplify your rulesets and make sense of them, they are all over the place.
Try to find common themes by grouping use cases together.
It may be useful to use firewall address lists and interfaces to reduce the number of rules.
There certainly is duplication that can be avoided and that stems from poor requirements planning…
(14) DESTINATION NAT…
Didnt find too much off here. I dont know why you have RDP in the mix, thats usually a security nightmare that attracts unwanted attention. Is there anyway to avoid that like use wireguard vpn instead LOL.
This rule - get rid of the in-interface not helpful…
add action=dst-nat chain=dstnat dst-address=10.199.6.39 dst-port=5101
in-interface=PC_LAN protocol=tcp to-addresses=10.1.5.101 to-ports=5101
(15) If you have users using the WANIP to access servers (vice direct LANIP) and the server is within the same subnet as the user you will run into hairpin nat issues, but I dont know if that is the case.
(16) Set to none, its not a secure access method
/tool mac-server
set allowed-interface-list=NONE
(17) Set to management interface…
/tool mac-server mac-winbox
set allowed-interface-list=Manage
