Date: Sat, 3 Feb 2001 09:45:04 -0600 From: "Thomas T. Veldhouse" <veldy@veldy.net> To: "Keith J" <kjohnso8@columbus.rr.com> Cc: <freebsd-stable@freebsd.org> Subject: Re: Bridge and IPFW woes ... Message-ID: <000801c08df8$46e3bd70$0100a8c0@cascade> References: <006801c08d39$6974f9e0$3028680a@tgt.com> <008a01c08deb$1d8d3bc0$3601a8c0@keefer>
next in thread | previous in thread | raw e-mail | index | archive | help
> I am curious... what are you using for GW route entries for Host A, B, C? They all use the default gateway assigned by the ISP - in this instance we can say 24.2.0.10. > > Try pointing B & C GW / default route to the Host A internet interface IP. > Then add a static route entry for Host A's internet interface to push all > 24.2.0.x > net traffic to the internal (24.x.x.x) interface (be specific as shown lest > you loose > all outside world access to any 24.x.x.x address!) Let the internet > interface > make all bridging / routing decisions. I am not sure I get what you mean here. > > With DHCP running the default GW interface for B & C would be 24.2.0.1 > and it appears Host A 24 net is bridging to Host C when B talks and vice > versa. Granted bridging should pass everything to every interface, but > obviously > that is not the case here and you should be glad.... because - > > I am not sure why you believe Host A can be a firewall to Host B & C and do > bridging. Firewall packet inspection is done at the IP level, if bridging > occurs > before this step the firewall is completely bypassed, and in both > directions! > Interface bridging is the same as plugging everything into a hub unless you > are > filtering by MAC addresses. IPFW does only filter IP - but the firewall code is set to deny everything by default - and the documentation states that it does indeed deny verthing - including ARP requests. To get ARP requests through - you need to add this rule: ipfw add 300 pass udp from 0.0.0.0 254 to 0.0.0.0 # pass arp for bridging Now IP and ARP are all that should be passing the bridge. > > Furthermore, even if you are getting to the firewall code bridging allows > all > non IP i.e. IPX, Appletalk, NetBui, etc. traffic to flow out of your network > to the internet side where, hopefully, your ISP is dumping it. On the other > hand, > if this is a "shared segement" as most cable / dsl systems are, anyone in > your > segment can see everything you are doing, internal log-ins, printing... etc. Yes, the segment is shared, but other peers on mysegment can not see me and I can not see them. I am connected to my ISP via a bridge, not a router. I think they route packets to the bridge, because I don't see any traffic for other hosts on my segment. > > A more robust / safe design would be to avoid bridging all together, and use > NAT > and a DMZ segment to perform your "network services". If you want to run > seperate services on Host B & C use Host A firewall port forwarding rules to > direct > traffic accordingly. If you absolutely positively need "outside world > appearance" with > extended URL's, run DNS on Host A to direct traffic to B & C. Yes, I agree. However, I need these hosts to have static IP addresses because these are my desktop machines that occasionally host games. At least one game in particular has a faulty protocol where it uploads its IP address instead of allowing the other end to determine it - thus everbody in the world would see 10.0.0.1 instead of 24.2.0.2 for host B. I am currently running IPFilter with ipnat which uses bimap to map the public and private IPs together, but it still does not work with this game (not to mention that ftp proxy is broken horribly in IPFilter 3.4.8 which is bundled with FreeBSD 4.2). Tom Veldhouse veldy@veldy.net > > Keith > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000801c08df8$46e3bd70$0100a8c0>