On 2006/10/12 01:15, ropers wrote: > 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.
Normally, you get a separate address _as_well_. Let's say 123.4.5.6/30. Say you don't run a dynamic routing protocol you would set the default route to 123.4.5.5. The internal network 123.123.123.0 is yours to play with and carve up as you like, say you take 123.123.123.1 and tell the other hosts in the subnet that's their default gateway. Provider receives packets for 123.123.123.123; their route table has 123.4.5.6 as the destination for 123.123.123/24 and sends the packets along. No promiscuous interfaces, this is just plain ordinary IP routing. > 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. Yes, bridging firewalls are useful where you don't have IP traffic for the whole subnet forwarded to your router by normal IP routing. The situation you describe is one. ISPs giving a `managed router' where they can't be bothered to manage it enough to add routing-table entries for you is another. > 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, OSI is just a model (-: > Neither do I understand what really goes on during IP forwarding as > opposed to bridging with forwarding(routing) tcp/ip packets have a destination IP address which isn't bound to an interface on the router but the MAC address _is_ the address of the routers (destination address is not ARP'd for because the previous router knows it's not a directly-connected destination). with bridging, the MAC address is of the final destination, and is learned by the previous router by ARPing for it (ethernet broadcasts cross the bridge unaltered). see "tcpdump -e" > or, for that matter, why I needed to enable > net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work. I'm not sure you do, but I think you need it for PF. If it was a bit more sensible time of day I'd double-check (-:
