UDP broadcasts to WAN
-
But it also leaves little "tricks" like this gateway policy-routing thing that does not come into play on a single-port ordinary LAN.
So on an ordinary LAN the routing table comes first, and then the firewall, and then again the routing table, unless there is a policy route? Sounds complicated. Why is it different for a bridge?
Risto
-
According to a PM I received, cmb stated that by the time such traffic from a bridge is evaluated, it is not possible to tell if it is a broadcast or not. I take that to mean there is no longer a way to reference the subnet mask of the bridge interface itself.
I see this as something that is a surprise to pretty much everyone. Let everyone know that if they use a bridge to put a wireless card on the same subnet as their LAN, they will leak information out WAN they probably don't expect. In my testing it was netbios hostnames and internal IP addressing schemes.
I was already putting explicit, quick floating rules on interface group V4WANS outbound blocking RFC1918 and alias local_v4_network destinations. Today I will probably add This Firewall (self). I let the interface checkboxes handle WAN in, though a floating rule blocking alias local_network sources wouldn't be a bad idea. But I think there's some automatic spoofing protection already present.
In summary, the following still applies:
-
Don't bridge. Use a separate subnet for multiple interfaces.
-
Don't use a wireless card, get an AP.
-
Don't bridge ethernet, get a switch.
-
And, in this case, get a switch that does what you need to have done at layer 2 - don't use your router to do your switch's job.
-
Just because you can, doesn't mean you should.
-
-
http://www.ebay.com/itm/CISCO-WS-C2950T-48-SI-48-Port-Switch-10-100-Ethernet-Ports-REFURBISHED-/321672574121
The shipping costs to Finland are unacceptable, but of course I could take a look at the European eBay offerings.
Yeah. It was intended to be an example. There are likely cheap, surplus switches all over the world especially if 10/100 station ports are acceptable. That one has gig uplinks.
-
Why am I getting a strange feeling that some people following this conversation hope that it wasn't ever started, and the whole problem had been kept under the carpet? Probably just my imagination.
Well, I'm glad it was. It certainly has opened my eyes :)
And thanks to all of you for your opinions.
Risto
-
I don't get that at all. We told you from the start that your config was convoluted and unnecessary. You're poking around in areas that get very little attention since there are vastly better ways to accomplish the same thing.
-
The shipping costs to Finland are unacceptable, but of course I could take a look at the European eBay offerings.
There are many at Ebay UK. You should be able to find a 48 port for around €1 per port incl. shipping. More expensive than in the US but still very reasonable.
Now that I found them, I'm almost sad that I don't need one…
-
I don't get that at all. We told you from the start that your config was convoluted and unnecessary. You're poking around in areas that get very little attention since there are vastly better ways to accomplish the same thing.
Well, think again. Since bridge and policy routing are both apparently useful features, it's about time to unveil the fact that they should not be mixed in pfSense. Could happen to anyone.
Risto
-
But it also leaves little "tricks" like this gateway policy-routing thing that does not come into play on a single-port ordinary LAN.
So on an ordinary LAN the routing table comes first, and then the firewall, and then again the routing table, unless there is a policy route? Sounds complicated. Why is it different for a bridge?
Risto
On an ordinary LAN packets that are received for an IP broadcast address (e.g. 192.168.1.255 on CIDR 24) have "arrived" by definition when they hit the network stack of every node on the LAN broadcast domain. That includes the pfSense router. The network stack can just hand the data in the packet to whatever application (if any) in the pfSense is listening for such things.
When a bridge is done, the network stack has to act smarter. pfSense is being "itself" and a bridge at the same time, so it should do the ordinary bit above, but it also has to re-broadcast the packet on all other interfaces in the bridge, to make sure that other devices in the bridged broadcast-domain will get a chance to see the packet.
The handy bit is that, even though "bridging" is really a layer 2 thing, it is also doing layer-3 filtering on the packets - if you want to filter what is bridged you can do that.
The annoying bit is that, even though "bridging" is really a layer 2 thing, it is also doing layer-3 filtering on the packets - it applies the darned filtering rules to the packets, which includes policy-routing and any other weird and wonderful parameters you can add to a "pf" rule - and thus for packets that match those sort of rules it does not look like the bridge the user was expecting!
-
On an ordinary LAN packets that are received for an IP broadcast address (e.g. 192.168.1.255 on CIDR 24) have "arrived" by definition when they hit the network stack of every node on the LAN broadcast domain. That includes the pfSense router. The network stack can just hand the data in the packet to whatever application (if any) in the pfSense is listening for such things.
When a bridge is done, the network stack has to act smarter. pfSense is being "itself" and a bridge at the same time, so it should do the ordinary bit above, but it also has to re-broadcast the packet on all other interfaces in the bridge, to make sure that other devices in the bridged broadcast-domain will get a chance to see the packet.
The handy bit is that, even though "bridging" is really a layer 2 thing, it is also doing layer-3 filtering on the packets - if you want to filter what is bridged you can do that.
The annoying bit is that, even though "bridging" is really a layer 2 thing, it is also doing layer-3 filtering on the packets - it applies the darned filtering rules to the packets, which includes policy-routing and any other weird and wonderful parameters you can add to a "pf" rule - and thus for packets that match those sort of rules it does not look like the bridge the user was expecting!
Very good explanation. Even I understood (I hope). Gives me a thought: if we know that all bridge ports are private (maybe this 'bridge' should be called something else), there is nowhere to forward to, and the whole bridging phase could be skipped.
Risto
-
For the record: I got a Cisco 2950. It has its benefits in my setup, no doubt about that.
Risto