It has one physical Ethernet adapter and that's why I thought a virtual VLAN adapter could get its guests into another bridge. Moreover, I thought that access to the debian server would still be available because it is attached to bridge1.
In the world of "normal" networking devices, you cannot take a particular VLAN from a member port of one bridge and connect it to another bridge. Only Linux-based networking allows to configure things in such an extraordinary way. And I strongly prefer and recommend to use an extraordinary solution only where the goal cannot be accomplished using an ordinary one.
Do you literally mean "single bridge" like in my vlan-diagram? Not sure how to visualize the hybrid port.
Yes, I do, I mean a single common bridge for multiple VLANs, some of them playing the roles of WANs and others playing the role of LANs (in general case, here you'll have a single LAN and a single WAN).
There is no need to visualize a hybrid port in some special way. If the port is colored the same like one of the VLANs, it means that that VLAN passes through that port tagless; if other VLANs are shown to pass through the same port as well, it is a sufficient indication that the port is a hybrid one. Using this approach, a colored port with no other VLANs than the same-colored one is a pure access one, and a port whose color doesn't match any of the VLANs passing through it (ideally some shade of gray) is a pure trunk one.
Thinking on how to visualize the "redirection" of a VLAN from one bridge to another would have lead you to thinking on what would be necessary to actually implement it.
Do my blue (VLAN 111) and green (bridge+other ether ports) elements reflect that?
I wish I was so comfortable with drawing like you are (see
this for comparison, it took me hours), but no, the drawing is still not self-explanatory and needs an accompanying text. From the drawing alone it is not clear that the virtual machines run "inside" the Debian server and that VLAN 111 passes through ether3 of 4011 and eth0 of the Debian server. I know I've said to concentrate on the logical topology, but this particular moment (eth0<->ether3 connection carrying two VLANs) is critical for grasping the overall scenario. Also describing the links (arrows) with names of interfaces to which just one end of the link is connected may introduce confusion.
If I understand correctly, RB4011 gets it's 192.168.1.0/24 IP address via DHCP client on vlan111 interface like Ether1 and Ether2 and all virtual machines that use VLAN 111 tagged virtual network adapter.
Exactly.
From what I read, I was under the apparently wrong impression that I would need a second bridge.
This was true many RouterOS versions ago, where you needed one bridge per VLAN to be able to affect membership of ports in VLANs. Before
vlan-filtering, all frames were bridged to all other ports of the same bridge, and no tagging/untagging on ingress/egress was possible, it had all to be done using
/interface vlan.
As you described, I can tag ether1 and ether2 so that those device do not need to be VLAN aware. Am I right that this approach requires VLAN Filtering enabled on bridge1 aka bridge_lan because of the tagged ether-ports?
Yes, as explained above.
If the router-modem and the IP-phone where able to tag their packets with VLAN ID 111, VLAN Filtering would not be needed?
For this exact scenario, correct, you could have the WAN VLAN (111) and the LAN VLAN (1?) on the same bridge even with
vlan-filtering=no. But
vlan-filtering=yes is also necessary to allow the actual "filtering", i.e. without it, VLAN111 would be available also at the other Ethernet ports, which is not desired in many cases.