Bridge network and filtering (on individual interfaces and bridge)
-
I have an APU2 device with the following setup
------------------ WAN1 -> | | WAN2 -> | pfSense | LAN -> | | KETTLE | (USB) | ------------------
I also have several VLANs setup on the LAN interface, specifically one called Kettle2 and another called Wireless.
I've created a bridge interface from Kettle (ethernet USB adapter), Wireless, and Kettle 2. I've assigned an IP address 10.0.133.0/24 to this bridge and setup DHCP.
For test purposes I have a port on a switch (connected to LAN) which is a member of the Kettle2 VLAN and I also have a WiFi access point connected to the KETTLE network over the USB-ETHERNET adapter.
If I connect an iPad over Wifi and laptop to the switch they both get IP addresses in the correct range.
The reason for this setup is that I have a Smart Kettle and various other IoT devices that I don't trust on my main LAN but that thinks like iPads/phones need to see in order to configure/work.
So my thought was to use a bridge network so that the IP traffic is all on the same subnet and I can then control how each segment accesses the others and more importantly how they can connect to LAN resources and the internet via the WAN.
The problem I have though is that, with pfSense firewall rules I only seem to be able to filter on the bridge (bridge0) interface as a whole, allowing traffic in/out to the internet. I've not as yet bothered too much about packets traversing the bridge as I'm more interested in locking down each part of it.
I've currently got the following tunables set
net.link.bridge.pfil_bridge 1 net.link.bridge.pfil_member 1
I wondered whether the effect of these was only relevant at the point I create the bridge, so I deleted it and started again. Didn't seem to make a difference.
What effect does changing these actual have? Is it actually changing how the filtering works immediately or does pfSense need to be restarted?
I set no IP addresses on any of the bridge members, only on the bridge0 interface itself (this seemed to be the consensus of the posts/documents I read on the topic). I have noticed however that the interfaces all have IPv6 addresses (I'm not using IPv6 at the moment).
If I setup firewall rules on members of the bridge, e.g. for HTTP(S) there are no states shown, it's as if the rules don't match at all. Rules on the bridge0 interface do appear to be being hit and in fact I need to explicitly allow traffic to get to the internet. However this access affects all members equally which isn't what I want.
I also tried setting up rules on the members that would add tags and then attempting to block these on the bridge, again, no success.
Would a solution be to add fixed IP addresses to each member interface (and the bridge) on the same subnet and would this then allow rules with source of, say, "kettle" to be set for traffic coming from that segment?
-
In my experince those sysclts do only apply when you create the bridge so they need to be set before doing so.
Just reboot if you have chnaged them afterwards.I expect to be able to filer on both member ineterfaces and the bridge but that's not a conguration I have tested.
You can only have an IP address on one interfaces in the bridge (in the same subnet) and putting it on the bridge interface itself prevents the DHCP server going down as the bridge itself is never down.
Steve
-
@stephenw10 thanks for the reply.
Yes, I tried rebooting after changing the settings and also re-creating the bridge afterwards. That didn't seem to make any difference. I still can't filter on the member interfaces.
I tried adding IP addresses to each member before adding to the bridge and it wouldn't let me use the same subnet on all of them so, as you point out, that's not the way to go.
So I'm still stuck with a bridge that doesn't seem to allow me to achieve what I want: individual filtering on each member interface.
-
Does it work as expected if set net.link.bridge.pfil_bridge back to, filter only on the member interfaces?
One thing to watch out for is that because the interfaces have no IP the rules cannot use the system aliases as the source such as 'LAN net'. That is not valid and would not match any traffic.
Steve
-
@stephenw10 I'll don't believe any settings have given me what I wanted - I can try again tonight when I am back home.
I can probably construct rules that don't care about source just destination. The rules are grouped as per interface under the pfSense Rules UI.
Is there a way to debug rules/bridges using the UI or command line?
Is there a way to see what interfaces a packet goes through? Maybe tcpdump?
Will the packet filtering on member interfaces even work at the TCP/IP layer at all? Is the bridge just copying all the frames to the bridge0 interface and can only filter on that?
-
pf only filters at layer 3, it still works the same way on a bridge. I've setup filtering bridges like that in the past a number of times and it has worked fine.
There's no way to debug at the command line I'm aware of. You can pcap on the various interfaces to see what's happening there.
Steve
-
Hi
I am afraid I have the same issue over here, although i have found a solution, but i do not know if there are other implications or not.
Pfsense 2.4.4 p3 on a box with several interfaces, Wan1, Wan2, Lan3,Lan4,Lan5. I set up the bridge with the 3 Lan interfaces and set the ip on the bridge from the beginning, as I was using another interface to configure the box. Only Wan1 is used by now and Traffic shaping with HSFC is configured on the bridge with floating rules on WAN (and it is working great btw for a 5Mbps/400Kbps DSL line). OpenVPN tunnel is used also to connect and do Lan2Lan routing between two locations.
I did not modify the Tunables, but filtering started working on the Bridge as soon as it went up, and actually I had to create rules to allow traffic on it, no rules were created on the physical interfaces, only in the bridge and it worked flawlessly.
Looking at the Tunables now they are:
net.link.bridge.pfil_bridge =0
net.link.bridge.pfil_member=1However, filtering is not working at the physical interface but at the bridge which is unexpected. Maybe it is relevant to point out pfsense is doing routing, and not NAT in my case, as there is another router box doing the NAT to the internet, and i am using static routes between the router and pfsense.
No matter what combination of values i use in the tunables, filter is always happening at bridge, not at physical interfaces.I have tried and rebooted pfsense several times.
HOWEVER, taking a look here https://www.freebsd.org/cgi/man.cgi?bridge(4), there is a mention to net.link.bridge.pfil_local_phys, which i was not aware of. As soon as i set this to 1, i was kicked out the pfsense as there were no allow rules in the interfaces but on the bridge and I was on one of interfaces affected.
With this tunable on, rules are enforced on the physical interfaces and rules on the BRIDGE are completelly ignored (and also shaping rules based on the bridge are also ignored, and i was using some of them to send traffic to a queue coming from openvpn, had to change to all 3 interfaces instead of bridge)
I was expecting somehow that both set of rules were enforced, physical first and bridge second, but anyway, this is ok for me.
I do not know if there is any relation between the fact that i am doing routing and not nat and net.link.bridge.pfil_local_phys but it is working for me although probably there are other implications i am not aware of.
Hope it helps, and if someone can provide some light to why pfil_member/pfil_bridge tunables are not working as expected or if there is any option to chain physical and bridge rules that would be great
Emilio
-
Hmm, curious. I have never set that sysctl and never seen that behaviour.
I have a bridge setup here now and it filters on the member interfaces as expected with the defaults set:
[2.4.4-RELEASE][root@5100.stevew.lan]/root: sysctl net.link.bridge net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0
However on that system the bridge interface is not assigned. I had no need to for that particular application.
You might try unassigning it and see what difference that makes.The pfil_local_phys sysctl appears as though it should only affect 'locally destined packets' I would not have expected it to do anything for routed traffic.
Steve
-
When you say kettle, you mean like an actual kettle - something that boils water?
Something like this?
https://www.myappkettle.com/My point in asking is - you seem to be complexing up the network for something that could have a much simpler solution to what your trying to accomplish. Understaning the device(s) your talking about and understanding how they function and what your actually wanting to do gives us the details needed to find the simple solution that meets your desired goals.
Bridging to be honest, should always be the last possible solution.. So unless your needing to bridge 2 different media types - like fiber and ethernet and the only device you have that has both is pfsense. I would prob still suggest just getting a simple media converter.. Reading your thread, and just at loss to why anyone would want/need to go through such a complex setup to do something simple like isolate an IOT device from the rest of your network.
As example - my roku stuff is all on its own segment and have a chromecast on that same network.. So if my wife wants to say cast to the chromecast from her ipad.. I have connect the ipad to the "roku" network vs the normal other network..
-
Kettle dude is long gone, this is a hijack!
-
oh... Didn't notice is was different nick..
My point of bridging being the last possible choice ;) Still valid though.. hehehe
-
Hi there
Bridging is working ok for me, just wanted to point out that the bridge tunables sometimes are not working as expected (I do not know why) and the workaround I found (Wan interface is also using private address 10.0.0.0/8, so maybe that's the reason why net.link.bridge.pfil_local_phys works that way)My motivation for bridging is exclusively traffic shaping not properly working with two lan interfaces; I only have 5Mbps/400Kbps adsl line @Home and after a lot of reading in these forums, I have been able to to use HSFC to have a reasonable experience for the whole family; we can browse internet, watch youtube videos, play ps4 games and download some torrents from time to time, all at the same time without conflicting (a lot) each other.
Now I just wanted to to do some wireless filtering for IOT and others, I can do it with just one pfsense interface + a switch without issues, but from my readings it seems that the recommended way is Wifi/Lan bridging and this is where my tests were headed.
Now everything is working great with bridging (with the small exception of port redirection and unbound), but happy to learn and test any suggestion for doing such isolation without affecting traffic shaping.
Thanks!
Emilio -
I agree it seems like odd behaviour.
It would be interesting to test with the bridge unassigned if you're able. That could be inconvenient to setup though.
Steve