@viragomann Thank you for your advice. This is in line with what I found out so far.
In more general terms, here is what I found:
1: It is possible to create a bridge between a tagged VLAN interface and an untagged LAN interface just like between two untagged interfaces, except if the tagged VLAN's parent interface is also a member of a bridge. See here for more: https://redmine.pfsense.org/issues/11139. For example, if LAN on ix0, VLAN10 on ix0.10 and LAN2 on ix1, then I can create a bridge between VLAN10 and LAN2 if, and only if, LAN is not a member of a bridge.
2: This bridging works well between a WAN interface and a VLAN, which itself is bound to a LAN parent interface. To use the example above, this would be between the WAN interface and LAN10. In my case, where the WAN is a "private WAN" behind an Internet facing gateway (ISP-GW), the Netgate's WAN interface (like any other member interface) can be configured to receive an IP address via DHCP (but not have a DHCP server) from the ISP-GW (192.168.192.0/24). All other devices connected to this bridge will also be able to receive an IP address from ISP-GW. Note that all addresses on member interfaces and all connected devices are (must be) in the same subnet. Also note that, generally, this does not work without the double NAT/gateway setup, because it would need multiple IP addresses from the ISP.
3: For DHCP address assignment to work, a firewall rule may be required on all bridge member interfaces (except probably the one where the DHCP server resides): source 0.0.0.0, source port 68, destination address 255.255.255.255 and destination port 67. This message is the first to be sent in the DHCP protocol. There are two aspects to this that I don't fully understand yet:
3.1: The rule may not be required if one of the bridge member interfaces receives a DHCP address. It seems that pfSense automatically adds a hidden rule to that effect. What is not clear to me is whether this hidden rule applies only to the bridge member that receives a DHCP address, or whether it applies to all bridge members.
3.2: I don't understand the role of the system tunables net.link.bridge.pfil_bridge and net.link.bridge.pfil_member. It is easy to find a variety of explanations for these, but none of these is complete. There are two aspects of firewall rules in brides and bridge members: a) govern the traffic between the bridge interface or a member interface entering/exiting the firewall/routing engine, and b) filtering the traffic between the member interfaces without it entering the firewall. I suspect the system tunables apply to the first aspect, but not to the second.
3.3: Testing of this is complicated by the facts that a) devices cache their IP address and use the last address when trying to renew an address lease, and b) the bridge caches the MAC addresses on each bridged segment. When changing the firewall rule mentioned above and the system tunable settings, all the caches need to be flushed to determine the impact of the change.
4: Concerning the propagation of the traffic on the Unifi switches (and I assume this is similar to other managed switches): to make this work the only thing required is to declare the VLAN, without specifying DHCP/seubnet/gateway parameters. This makes the switch aware that the VLAN exists. The VLAN can then be added to trunk profiles (as tagged traffic) and to port profiles for VLAN-unaware end nodes' access to the untagged data stream.
I will further update this when I have gained a better understanding for 3.2.
Any further comments are welcome.
Peter
