Bridge Interface - Firewall Rules on member not working
-
Hello Guys,
Iam trying to setup a "pseudo" DMZ for my IoT Devices ( Echo, Sonos, Chromecast, smartplugs etc. on another ssid/vlan ).
Because i still want to use all smartphone apps and features, the iot devices need to be on the same subnet as the clients (mdns discovery, multicast etc…).
So i made a bridge Interface Br1 with two members Opt1 + Opt2 for testing.My Problem is that i can only filter traffic on the virtual bridge br1, but i want to be able to filter
on the Member Interfaces ( allow only specific domains for wan traffic and filter traffic between member Interfaces Opt1, Opt2 for example. )
Only the rules on br1 are working, nothing happens when i make a block any any rule on Opt2.
Iam running latest 2.4.3 dev. Systemtunables are set for member filtering: net.link.bridge.pfil_member 1; net.link.bridge.pfil_bridge 0What Am i doing wrong here :)? Or is it a bug maybe?
*Offtopic: how you guys filter your IoT Devices ( bridge multicasts to other vlan subnet ?, mdns proxy?! ).
-
"the iot devices need to be on the same subnet"
The same as what? Your echo does not need to be on the same L2 as devices it controls. If your trying to cast to your chromecast from a device yeah its easier if they are on the same L2.. But you should be able to work around that with avahi..
Why are you bridging interfaces on pfsense? Why would you not just use your vlan switch for devices that need to be on the same L2.. Are you wanting to filter device A from B that are on the same L2?
-
Why are you bridging interfaces on pfsense? Why would you not just use your vlan switch for devices that need to be on the same L2.. Are you wanting to filter device A from B that are on the same L2?
yes, exactly. I want to Filter device A from B on the same subnet. ( I have also a docker-host with other services (hue-emulator wemo-emulator etc.) that need to be on the same L2, so my plan is to filter the devices among themselves and access to WAN. BTW the echo controls wemo switches over local net, not amazon cloud/api ).
-
Well lets see your rules and what your trying to filter exactly.. When you created your block any any, did you clear your states?
How exactly are these devices connected.. For all we know you have a loop that bypasses pfsense bridge at the switch layer?
-
I had only 1 Member-Interface in the bridge for testing, that didnt worked because i tested with external ip.
Now i have the setup as i discribed it: br1 with opt4 and opt5 as member. I have one client on each member for testing.
The blocking Rule on opt5 is working kind of (i can´t reach the client on the opt4 interface anymore, as aspected), but i can still ping 8.8.8.8 or the bridge interface (192.168.2.1) with the client on opt5 where the rule with block any any is active?!
Why is that, is there any doc how this "cascading" of firewall rules on a bridge/member Interface works?Best Regards and thank you for your help :)!
-
No sorry you wouldn't be able to get anywhere on this client connected to opt5.. Not with those rules
Did you clear the state..
if you ping 8.8.8.8 from device on opt5 side.. And then put in a block rule, until that state goes away then that device would still be able to ping 8.8.8.8
Also how do you have devices connect to opt4 and opt5? Is this connected to same switch? How is the sonos setup - they can be notorious for creating a loop if running their wifi network and wired, etc.
-
yes, i reset the state table (and rebooted to be sure).
i can definitely ping 8.8.8.8 from the client on opt5 ( when i ping the client on opt4, the state-details packets count up on the opt5 Block any Rule. When i ping 8.8.8.8 the Pass Rule on br1 counts up. )
The clients are vanilla ubuntu server on hyper V, they both have a separate privat virtual switch -> 2 Interfaces hn3, hn4 on pfsense ( so there cant be a leak, both clients have isolated connection to pfsense members ). There is nothing else on the network, its greated for testing with only the two clients on opt4 and opt5.
Very confusing :o. -
You can run a packet capture on both interfaces and check the traffic flows
