<![CDATA[Bridgeing: 2nd bridge does not pass traffic]]>Hi all

I'm having a bit a hard time here getting two bridge interfaces running. Requirement is simple: accesspoint serving two SSIDs, each connected to an appropriate VLAN. Switchport provides untagged traffic for wlan1, and .1q tagged traffic for wlan2. There are already dhcp-servers and gateways available on these segments, so the pfsense does only L2 connectivity by extending these networks into the air.


Bridge0:	vr0_untag,  vr1_untag,  ath0_wlan1 (hostap)
Bridge1:	vr0_144,  vr1_144,  ath0_wlan2 (hostap)

While setting this up was no problem, I'm having quite a tough time using the 2nd bridge. From my understanding and experience you can usually set IP addresses to both, the physical-member as well as to the bridge interface, so I should be able to dhcp-up all four interfaces: both Ethernet and both bridges, not?

What works for me is:


vr0_untag 	DHCPC -> fine, gets an IP from DHCP on vlan0
vr0_144 	 DHCPC -> fine, gets an IP from DHCP on vlan144
bridge0		DHCPC -> fine, gets an IP from DHCP on vlan0
bridge1		DHCPC -> fail, never gets an address

the problem with bridge1 is also reproducible when clients are connected to these bridges:
wlan clients connected to ath0_wlan1 are getting onto the vlan0 network, all good
wlan clients connected to ath0_wlan2 are getting dhcp'd, but cannot communicate otherwise

this is very strange: I can see the DHCP-chitchat through bridge1, but see nothing further. Whatever the clients are doing after getting the ip: it's just not visible! Even arp-whohas won't get though, I cannot arp-resolve the ip of the dhcp server, just blanc.

I made sure that there are enough IPs on the servers, doublechecked the switch (though vlan144 is fine otherwise vr0_144 would not get an ip neither), even made the same config to the 2nd Ethernet interface (vr0): exactely the same: native works just fine, vlan'd port does barely supply an IP that’s it. For analysis I've been through all combinations net.link.pfil_*, and also disabled all packet filtering, nothing.

Difference from bridge0 to bridge1 is only that the later has a vlan-tagged member … but I've seen this working before.

As I'm running out of ideas I was wondering if there's something I missed? Just having a 2nd bridge interface should not be a problem, not?  I've searched a lot in this forum but found only one bridge confirmed to work ...

Cheers
Alix hardware with 2.1-rel

]]>https://forum.netgate.com/topic/66537/bridgeing-2nd-bridge-does-not-pass-trafficRSS for NodeFri, 13 Mar 2026 21:03:29 GMTMon, 10 Mar 2014 10:37:14 GMT60<![CDATA[Reply to Bridgeing: 2nd bridge does not pass traffic on Mon, 10 Mar 2014 11:53:37 GMT]]>and thats it: do not mix untagged and tagged interfaces with bridges.
final hint came through this discussion: https://forum.pfsense.org/index.php?topic=31539.0

sorry for bothering

]]>https://forum.netgate.com/post/448028https://forum.netgate.com/post/448028Mon, 10 Mar 2014 11:53:37 GMT<![CDATA[Reply to Bridgeing: 2nd bridge does not pass traffic on Mon, 10 Mar 2014 11:36:44 GMT]]>i exchanged the bridges numbering with the same result: only the untagged-bridge works, the tagged does not, i cannot get an IP onto the bridge interface with vlan member.

though if there is no bridge that includes the untagged vr0, the bridge with vr0_144 works fine.

so what does not work is: bridge a vlan-member if it's untagged parent is part of another bridge … grrr...

]]>https://forum.netgate.com/post/448024https://forum.netgate.com/post/448024Mon, 10 Mar 2014 11:36:44 GMT