On 11/10/06, Martin Gignac <[EMAIL PROTECTED]> wrote:
Hey Jens,
On 10/11/06, ropers <[EMAIL PROTECTED]> wrote:
> OTOH, if you do have enough public IPs to play with, I'd still
> consider bridging and using only public IPs (then you don't need to do
> VLANs or NAT).
To satisfy my own curiosity, what are the advantages in your view that
bridging offers between the internal and external interface compared
to using typical ip fowarding?
(Note: I've never worked with bridging on an OpenBSD firewall, so I'm
a newbie at it.)
I have limited expertise myself --while I do claim some OpenBSD
experience, that experience is has its limits and I can't code. So
here's my understanding, but if I'm wrong anywhere I would be very
happy to get corrected:
Let's assume I have am OpenBSD box with adapters $ext_if and $int_if,
and $ext_if is connected to a switch on a WAN, and $int_if is
connected to a switch that a number of hosts are connected to. Let's
say on the WAN IP subnet 123.0.0.0/8 is being used. Now I somehow want
to provide firewall protection to the hosts on the $inf_if side.
I could use NAT and give both the $int_if and $ext_if NICs IP
addresses. That way I sould make the part on the $int_if side into a
subnet using eg. 192.168.0.0/16. I could assign 123.1.2.3 to $ext_if
and 192.168.1.2 to $int_if. I would not use bridging and none of the
NICs would be in promiscuous mode.
Or maybe I have gotten a small chunk off of that big fat 123.0.0.0/8
network to play with. So let's say I have been allocated
123.123.123.0/24. I would put the external interface in promiscuous
mode (echo up > /etc/hostname.if) but assign an IP to the internal
one, say 123.123.123.123. This IP would be my default gateway on the
internal hosts. They need to know where the heck to send packets that
aren't for hosts on what's now their own local subnet. Apart from the
fact that I'm using IP addresses of the same type (public in this
case) on both sides of the firewall, and that those IPs have to be
properly assigned to/subnetted by me, I'm still king in my castle --
my 123.123.123.0/24 subnet can be fairly independent.
Finally, I could use bridging. This puts both NICs in promiscuous
mode, even if I assign an IP address to one of them, which is a good
idea to allow remote administration (I could assign IPs to both but
there's prolly no good reason to). Also I could decide to only allow
local/serial console administration, and on purpose don't give IPs to
either NICs. With bridging, both sides are logically on the same
network segment, it's as if the network parts in front and behind the
firewall were just one physical network segment. This is transparent
bridging. Neither host on either side needs to even know that that
bridge is even there. And indeed it would be largely useless (well,
useful for range extension beyond max cabling lengths) as long as it
weren't also filtering. Once you packet filter on the bridge it
becomes a magic cable that's just part of a larger segment, but for
some reason doesn't allow garbage through. Good if you have to share a
subnet with undesirables.
I have a setup where there's a switch that's directly connected to the
Internets, that's outside of my control, and that "my" Windows Server
2003 Domain Controller has to share with third parties. Yeuch! So I
put that box behind an OpenBSD nanny^Wbridging firewall. Trouble is,
there are all these other hosts outside that firewall who are directly
connected to the switch, and these all need to talk to the DC and
expect it to be on the same subnet. Also, I want to put more hosts
behind the firewall. No problem with bridging.
I hope this makes sense.
What I don't really understand is where bridging actually takes place,
and what happens in case of a filtering bridge. I thought that
bridging per se happened at the data-link layer of the OSI model,
while packet filtering happened at the network layer.
Neither do I understand what really goes on during IP forwarding as
opposed to bridging, or, for that matter, why I needed to enable
net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work.
Cheers,
--ropers
PS: What was quite interesting to learn about is how to enable DHCP
requests (inclusive DHCPDISCOVER messages) from certain hosts to
traverse this firewall:
pass on $ext_if proto udp from { 0.0.0.0, <goodoutsiders> } port 68 to
$dhcpsrv port 67
pass on $ext_if proto udp from any port 68 to 255.255.255.255 port 67
pass on $ext_if proto udp from $dhcpsrv port 67 to { 255.255.255.255,
<goodoutsiders> } port 68
PPS: OT, but according to MS' official documentation, you can't turn
on the Windows Firewall on a DC (or if you do turn it on, the DC won't
work. But since putting the OpenBSD box in I've also learned that
there are additional solutions to the unprotected Win 2003 DC problem:
Core Force, building your own Windows "firewall" with IPsec and mmc,
hax0ring the registry of all DCs in the forest to constrain their use
of dynamic ports and then configuring exceptions for everything a Win
DC needs and turning Windows Firewall on regardless. I could elaborate
if people are interested, but I would do that in some Windows forum,
not here.
