Mailing List Archive

Philip Craig wrote:
> My most common use of bridging is a transparent firewall between
> the LAN and the WAN. This requires the ability to filter based on
> the outgoing port, which the current physdev match supports.
>
...
>
> So here is an ugly, inefficient, flawed, and barely tested patch
> which lets me do this. I have no expectation of this being suitable
> for mainline kernels, but maybe someone else is interested in it or
> wants to comment on the approach.
>
> The patch digs into the bridge internals too much, causes an extra
> bridge fdb lookup, ignores some const attributes, and probably has
> broken locking. And if there are no ARP or bridge fdb entries, then
> it doesn't match any ports.


Its probably also racy wrt. fdb changes. The thing I still don't get
is .. if you combine a bunch of devices in a bridge, why would you
care which port a packet will leave through? If you already know
behind which port something is reachable, why use a bridge? And if
you don't know I suppose you have nothing to filter by.

Patrick McHardy wrote:
> Its probably also racy wrt. fdb changes.

Yes. It could modify the bridging code to only forward to the
physoutdev stored in nf_bridge, or store the fdb result in
nf_bridge and avoid the second fdb lookup.

> The thing I still don't get
> is .. if you combine a bunch of devices in a bridge, why would you
> care which port a packet will leave through? If you already know
> behind which port something is reachable, why use a bridge? And if
> you don't know I suppose you have nothing to filter by.
>

The devices in the bridge represent different security zones.
Using a bridging firewall gives physical separation of these zones
without requiring additional IP networks or configuration changes
for the machines on those networks. The security policy has rules
defined primarily in terms of the zones, not the individual machines
in those zones. Matching on just IP address is not enough, because
it does not enforce the physical separation.

We definitely could configure the firewall to know which address
is behind which port, and enforce this in ebtables. This is the
solution Shorewall has used (I haven't looked to see if it enforces
the ports). But that requires more configuration. Basically it is
just a convenience argument. I'll definitely be trying to migrate
things to this setup though.

Philip Craig wrote:
> Patrick McHardy wrote:
>> Its probably also racy wrt. fdb changes.
>
> Yes. It could modify the bridging code to only forward to the
> physoutdev stored in nf_bridge, or store the fdb result in
> nf_bridge and avoid the second fdb lookup.

I remember now why I didn't do this already.
The solution is to store the result in the mark, and use that in
ebtables to ensure it still goes out that port. This needs to be
done anyway when defining the zone in terms of IP addresses.

Philip Craig wrote:
> Patrick McHardy wrote:
>
>>The thing I still don't get
>>is .. if you combine a bunch of devices in a bridge, why would you
>>care which port a packet will leave through? If you already know
>>behind which port something is reachable, why use a bridge? And if
>>you don't know I suppose you have nothing to filter by.
>>
>
>
> The devices in the bridge represent different security zones.
> Using a bridging firewall gives physical separation of these zones
> without requiring additional IP networks or configuration changes
> for the machines on those networks. The security policy has rules
> defined primarily in terms of the zones, not the individual machines
> in those zones. Matching on just IP address is not enough, because
> it does not enforce the physical separation.
>
> We definitely could configure the firewall to know which address
> is behind which port, and enforce this in ebtables. This is the
> solution Shorewall has used (I haven't looked to see if it enforces
> the ports). But that requires more configuration. Basically it is
> just a convenience argument. I'll definitely be trying to migrate
> things to this setup though.


I believe multiple bridges would be the best choice here, you
get the seperation for free.

>>The thing I still don't get
>>is .. if you combine a bunch of devices in a bridge, why would you
>>care which port a packet will leave through? If you already know
>>behind which port something is reachable, why use a bridge?

I just now saw this thread. I've been struggling with a similar
situation for a while now. I have two examples why I need to care about
the physical device and still bridge. First is a network I inherited.
I didn't and wouldn't build it this way. It has public IP Addresses in
the same subnet on both sides of the bridge. Some are "inside" systems
that need to be protected, others are "outside" systems, such as the
router that really need to be outside the firewall. Proxy ARP
definitely does not work in this case because the "inside" segment has a
load balancing system that does its own proxy ARP. So the firewall
proxy ARP and the load balancer proxy ARP fight with each other and keep
me up all hours trying to figure it out. The only viable solution is
bridging. But I still need a way to test for systems connected to which
physical NIC in the firewall.

The second example is a videoconferencing system using the H.323
conntrack module. I have situations with several older Polycom and
Tandberg codecs that never understood how to work in a NAT environment.
These need to have public IP Addresses, but I want them behind the best
firewall I know how to build, mostly so I can do some QOS at the network
boundary. I've been using proxy ARP for a while, but proxy ARP has its
share of problems. One problem is, it's very difficult to add new
devices to the network when the firewall proxy ARPs everything! So the
new device with address a.b.c.d tries to be a good neighbor and does an
ARP request to see if anyone already has the IP Address it wants to
assume. The proxy ARPed firewall answers - because it answers ARP
requests "in proxy" for everyone and everything, so the new device does
not asume the IP Address and come online. Bridging would solve this
problem nicely, but I still need a way to do tests based on the physical
interface.

Oh yes - proxy ARP also plays havoc with OpenSWAN and IPSEC tunnels.
These need an IP Address that belongs to one and only one interface. In
the past, I've taken a public IP Address from the block of addresses and
used this new address for tunnels. Again, bridging would be a great
solution, but it really needs a way to test for the real physical
device.

- Greg Scott