Date: Mon, 8 Jun 1998 01:09:06 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: wollman@khavrinen.lcs.mit.edu, net@FreeBSD.ORG Subject: Re: Documenting sysctls (was: Re: kernfs/procfs questions...) Message-ID: <9806080109.ZM28427@beatrice.rutgers.edu> In-Reply-To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> "Re: Documenting sysctls (was: Re: kernfs/procfs questions...)" (Jun 8, 4:57am) References: <199806080257.EAA15255@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 8, 4:57am, Luigi Rizzo (possibly) wrote: > fixed the missing link -- try again and thanks for pointing out the > problem Quite welcome. > (my code is not configurable at all for firewall purposes, > although it is so small and simple that it will be probably easier > to write some C code to filter unwanted packets than learning a > filter configuration language). Urk... I'm not much of a C programmer, so at least for now that's not a good alternative. (I say 'at least for now' since I'll eventually get replaced with an actual, professional system admin type - I'm a grad student in molecular genetics, not comp sci.) For instance, I really don't want to try recoding the 'keep state' solution in IP-Filter, which is nice for UDP for things like DNS and NTP. The same situation is probably true for other people who might be looking for a solution like this one, which is (one reason) why I've kept net@freebsd.org in the Cc:s. > there are some differences which might not be significant in your > application: > * some restriction on IP addresses you can put on > either side -- with a real bridge you can move machines around > without changing anything (including IP address), with this > setting you have to update the IP address of the machine you > moved. Yes, you do have to change the settings on the 'bridge' machine - but not on the machine being moved, unless there's something I haven't thought of. In general (and as per your second point), this method does have the problem of a more complex setup being necessary - the price you pay for configurability. > * you must fraction your address range and configure the routing > daemon on the machine acting as a bridge/router to make hosts > reachable from the outside; It's IP-Filter rules that handle it, not the routing daemon (although you could have the routing daemon doing it, at the cost of ttl decreases et al), but yes, this is a problem - see above. > * I am not sure how well this works with non-IP packets (e.g. we > have some MAC talking ethertalk around); It doesn't, at least at the present. This isn't a problem for our situation (especially since Macs and non-Unix PCs that are inside the Rutgers firewall are part of what we're trying to protect against), but admittedly might be for others. > * nor i am sure how well this works with ethernet _and_ IP multicast and > broadcast. Things like bootp might not work anymore across your > gateway. Ethernet broadcasts are supposed to be stopped by bridges, so I wouldn't consider that a problem - whether they are in this case is configurable through deciding based on what their IP layer stuff is. IP multicast and broadcast can be configured to be relayed through or not - letting it through only to whatever ports are necessary (e.g., tftp) would be possible. Admittedly, since we're not needing this functionality, there may be something here I'm not thinking of - I haven't had a cause to look into it, so I'm not as familiar with it as I might be. > it's more a bus than a CPU problem. I'll be going to PCI cards if we move to 100-Base-TX. > We are running 5 ports on a 386-25 here using my code (of course not > at full bw on all interfaces, but it can keep up with the filtering > decently) but just because i don't need to move all packets to memory. _Nice_. I'm impressed. Given that we've got some PCs around that aren't doing much (are getting replaced or whatever), I may consider using your code for doing bridging that doesn't need firewalling. In fact... it's nice for a firewall to have something resistant to sniffing between it and the rest of a network, since it might get broken into and bpf turned on... I might just stick one of those between the inner network and the firewall, running your code. Thanks, -Allen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9806080109.ZM28427>