The switch in question is unmanaged
A VLAN cannot be on either port - well it can, but the concept is to designate specific ports to carry tagged frames, so called trunk ports, and to designate other ports to carry untagged frames, so called access ports.
Why would you ever want to move the connection to the switch from em0 to em1 or vice versa?
The advice about the managed switch still holds - only managed switches feature trunk ports and tagged frames.
Ok, so what/which am I doing when I create a VLAN with a parent of em1? Clearly my understanding of this concept was more lacking than I thought... EDIT: After thinking about this some more, my thinking is that creating a VLAN with a parent of em1 is turning em1 into a trunk port - correct?
If so, then the question is how do I *also* turn em0 into a trunk port for the same VLAN, such that the DHCP server, etc, is available on that VLAN on both physical ports?
Why wouldn't I? The point of having two LAN ports in a bridged configuration is that they are interchangeable, and I don't have to worry about what is plugged into what - it's essentially just a two-port switch. Or what if I add another switch/access point on em0 and want to put some Guest network devices on that one as well, such that there are guest network devices on both ports?
Because as soon as an untagged port is a bridge member you cannot use that port for VLANs. Simply not possible. That's a constraint of the FreeBSD network stack. And that's because ... you guessed it ... FreeBSD is not a switch.HTH,Patrick
Interesting. Because em0 and em1 are bridge members in my configuration - and I was able to put em1 as the parent for the VLAN without issue, and it works.
Regardless, your point about OPNSense not being a switch is well taken. It sounds like I should find something else to do with that second physical port rather than trying to make it available as another LAN port - even if my CPU can handle the load without breaking a sweat, the system simply isn't designed for the use case I am envisioning.