Ok, lets go through this... > Hi, > > I have an OpenBSD 3.3 firewall which acts as a transparent bridge > between our network (not NATted) and a router giving access to the rest > of the world. The bridging interfaces are configured without IP address > and a third (management) NIC is configured with an IP address inside our > network's address space. A colleague of mine claims that this can lead
> to confusion in the routing/bridging code of the firewall and possible > corruption of the arp table. He says that the management interface He is talking crap. PF (or any other firewall I know of) doesn't know anything about arp tables, or even arp packets. You _can_ get issues if you have two bridge interfaces, as PF only has one kernel table. > should never be in the same logical or physical network as one of the > two sides of the bridge, i.e. it should have an address in rfc1918 space > and be physically connected to different networking hardware. This is because most switches are not security oriented and should be considered dumb hubs on all ports, all vlans. If anyone says this isn't so I'll beat them with enough references to flood a STM64... > I have difficulty in understanding how this could be true and he cannot > give me an explanation other than that he has had trouble with this in > the past (running older versions of OpenBSD 3.2 with ipf). Can someone > here enlighten me as to whether this is really a possible problem and if > so how exactly some sort of corruption/glitch could happen? Magic? bad administration? If Henning or Daniel haven't seen this behaviour, I doubt it exists. > Thanks a lot, > > Marc > > P.S. Naturally I am aware of the fact that having the management > interface on a separate NATted network with it's own protection is a > good thing security-wise, so that's not really my question. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
