Let’s translate the L2 term “VLANs” to an L3 term “connected subnets”, i.e. IP subnets in which the Mikrotik has its own IP addresses.
A connected subnet also needs a route; it is added dynamically (i.e. automatically once the IP address/mask configuration is added), with distance=0, but only to the default routing table (called “main”).
You seem to be another victim of wishful thinking, assuming that dst-address-type=local matches to any destination address from any connected subnet, while in reality it only matches Mikrotik’s own addresses. So by using dst-address-type=!local in the mangle rules assigning connection marks, you do not prevent packets towards local subnets from being connection-marked, so these packets consequently get routing marks, and the route for them is chosen among those bearing the same routing mark.
Since a matching route with that routing mark exists, these packets are routed out via WAN 1 or WAN 2 rather than being sent to the connected LAN subnet because the route for that subnet only exists in routing table “main”.
So while the topics title, “vlans do not work” suggests that VLAN tagging stopped working, actually routing between connected subnets (which in your case happen to occupy VLANs) stopped working.
But you want a solution, right? One possibility is to create an address list of all the connected subnets:
/ip firewall address-list
add list=connected-subnets address=192.168.1.1/24
add list=connected-subnets address=10.10.10.1/24
add list=connected-subnets address=10.10.20.1/24
add list=connected-subnets address=10.10.30.1/24
add list=connected-subnets address=10.10.40.1/24
and use dst-address-list=!connected-subnets instead of dst-address-type=!local in the action=mark-connection rules.
Another (simpler to configure but possibly slightly more CPU-intensive) way is to use
/ip route rule
add action=lookup table=main dst-address=192.168.1.1/24
add action=lookup table=main dst-address=10.10.10.1/24
add action=lookup table=main dst-address=10.10.20.1/24
add action=lookup table=main dst-address=10.10.30.1/24
add action=lookup table=main dst-address=10.10.40.1/24
to negate the effect of the routing-mark (route rules are evaluated just before route lookup and override or translate an eventually existing routing-mark assignment)
Unrelated to your issue, just to “structured-oriented firewalling”: whichever of the two ways above you choose, I would recommend you to use an interface list:
/interface list
add name=all-lans
/interface list member
add list=all-lans interface=LAN
add list=all-lans interface=vlan10
add list=all-lans interface=vlan20
add list=all-lans interface=vlan30
add list=all-lans interface=vlan40
and replace each 5 identical mangle rules differing only in in-interface value by a single rule using in-interface-list=all-lans instead.