VLAN's on Bridge interface not passing traffic
-
I'm having some trouble with VLAN interfaces on a bridge and I'm hoping the community can help. Attached is an image to help understand the issue.
I have two Wifi devices that both put out two SSID's (using Open-Mesh devices). One of the SSID's (LAN) has no VLAN assigned, the other SSID (LAN_US) is assigned VLAN 5. The LAN and LAN_US interfaces are Bridges (see image for the port and VLAN assignment for each bridge). The DHCP server is enabled on both LAN and LAN_US by pfSense.
LAN (bridge0) DHCP leases are assigned correctly and traffic flows without any issues for hard-wired and wireless devices.
LAN_US (bridge1) is where I start having trouble. DHCP leases are assigned correctly. For hard-wired devices on EM2, traffic flows without issues. Wireless devices (coming in on VLAN5) are not able to pass any traffic. They are not even able to ping the LAN_US interface address which assigned them their IP.
What could be causing the LAN_US bridge to not pass traffic for the wifi clients?
-
a) mixing tagged and untagged traffic on an interface is bad practice.
b) a bridge is not a switch
c) get a managed switch
d) do you filter on the interfaces or on the bridge? -
Bridges are intended to function as a switch. Filtering is done on the bridge. Mixing tagged and untagged traffic is quite common (quick example: VOIP phones on VLAN with computers attached and untagged) there is no problem to do this. I have other deployments of pfSense that use untagged/tagged on the same interface and it works perfectly (they do not have bridges though). The introduction of a bridge on this deployment seems to cause an issue with the routing.
This may be a limitation of IF_BRIDGE(4) (http://www.freebsd.org/cgi/man.cgi?bridge(4))
The Man page discusses a scenario of VLAN interfaces in the Bridge sharing the same MAC address with a physical interface. I confirmed the VLAN interfaces do have the same MAC address as the Physical interface they are attached to. This is where the tagging should come in as it's part of the Ethernet Frame. Does this mean that IF_BRIDGE(4) is not reading VLAN Tags? Would having a unique MAC on the VLAN interface resolve this?
Edit: spelling
-
A bridge is never a replacement for a switch.
Did you set the System Tunables:
net.link.bridge.pfil_member Set to 0 to disable filtering on the incoming and outgoing member interfaces.
net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface -
Yes the tunables are set as you have listed.
-
The more I look onto your Bridge Interface 'drawing' the less I understand what you want to do.
You have 5 physical IFs (EM1 .. EM5) and created 2 additional VLANs (EM3_VLAN5 and EM4_VLAN5).
Both are tagged on VLAN 5 ?What a mess. A small managed switch could clean that up nicely, don't you think?
-
Previously there was a switch doing the VLAN for this, but I had to return it to its owner so I had to improvise. There's enough interfaces on the device so I'm using them instead.
The drawing is just to show the interface and VLAN mappings. The idea is simple, LAN interfaces is one bridge and LAN_US interfaces is another bridge (both bridges route externally through different gateways).
The more I play with it, the more I think the problem is with IF_BRIDGE(4) itself not being able to differenciate between physical interfaces and VLAN's on those interfaces.
-
I'd think the problem is with your mingled interface and bridge assignments.
Get yourself a smart or managed switch and you're done. -
I thank you for trying to help, but you're missing the point of the topic and I'm not sure theres anything else you can add to be helpful in this instance. There's nothing 'mangled' about it. It's simply assigning a VLANs to members of a Bridged interface as required. I know how to fix it with a managed switch, that is not the issue.
My point is that VLAN's on Bridged interfaces don't appear to work as intended, or, I have something wrong in the configuration. If I have something wrong on the configuration side, I'd like to troubleshoot to know what it is. If there is some bug that affects VLAN's on Bridge interfaces, then I'd like to hear others input and see if they can replicate the issue so a bug report can be submitted.
