Date: Tue, 16 Jul 1996 13:11:59 -0700 (PDT) From: Jim Dennis <jim@starshine.org> To: rossw@albury.net.au (Ross Wheeler) Cc: questions@FreeBSD.ORG, darnison@albury.net.au Subject: Re: Question for FreeBSD Message-ID: <199607162012.NAA00636@starshine> In-Reply-To: <Pine.BSD/.3.91.960716174059.16405A-100000@orac.albury.net.au> from "Ross Wheeler" at Jul 16, 96 05:54:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Dear Sir! > > We have a FreeBSD box which will be connected via RS232 (serial) > interface to an existing BSD host. We are attempting to add a SMALL network > of ethernet connected machines to the FreeBSD host. These machines will > require access to the internet, but I really don't want to allocate > addresses to them from our (diminishing) IP allocation. > > I've heard from various sources that programs like wingate for windoze-95 > and some similar products allow additional PCs to use IPs in the reserved > 192.168.x.x range, and transparently gate them through to the net. I'm > not sure how (if) this can be achieved with FreeBSD, but hope you can > help us. This is called a "proxying host" or service. You'd install SOCKS on the FreeBSD host. The Trumpet TCP/IP suite allows transparent access between WINSOCK compatible applications and a SOCKS gateway. I guess the TIS FWTK (Trusted Information Systems Inc? Firewall Toolkit) also has a proxying service. I've never used it and haven't read enough about it to even guess that it might be compatible with SOCKS. That's the theory. I'm just trying to configure that around the house myself -- I'll let you know how it goes. The other approach is to use network address translation (NAT, a.k.a. "IP masquerading") -- Darren Reed's IPFilter package allegedly does this with FreeBSD (Linux has it built in to recent kernels -- a controversial design decision at best). Note: The difference between proxying and NAT is that proxying requires that the applications be written to the API (that they "know how to do it"). NAT doesn't require special clients. However there are still some applications that can't run through it. In addition it probably represents a higher load on the server. The decision of whether to use SOCKS, NAT or a combination thereof is largely a matter of your site security/"acceptable use" policy. If you want to provide your users with the most liberal and most transparent access possible -- use a combination (SOCKS for the supported applications -- NAT for some others and a "normal" multi-user host (accessed via telnet/ssh) for any remaining apps and acceptable services. If you want the most secure -- use SOCKS with a fairly restrictive configuration. Don't allow any NAT and put all services on strictly controlled servers. You may also want to install cached (or some other caching web server) on the proxy host, or a machine that is accessible directly from both networks. This can minimize the traffic between the net by allowing a large number of the web hits to be serviced from a host on the protected/hidden (private) LAN. > To date, we have managed to connect the FreeBSD machine to our BSDI host > via RS232, and have nameservice etc all operating happily. We can > alternatively, connect via ethernet and also things work fine. > > What we want to do, but have been unable to work out *exactly how* is to > use a *different* address block (192.168.x.x) on the ETHERNET (ep0) > interface and allow boxes attached to that ethernet segment to access the > internet via the RS232 link. If you have two interfaces -- with an address from one range bound to one, and an address from another range bound to the other than the machine will try to act as a router. Using SOCKS or NAT you don't want it to do that (configure the kernel forwarding "OFF"). > > There is a *slight* complication in that the machine will also have a > couple of indial lines (modems). These should also operate in a similar > manner to the locally attached Ethernet machines. You could assign private (RFC 1597) net IP addresses to each of the dial in lines. The host will then (you might also need static routes for each -- I'm not sure) > Don has previously set up ppp on one test port, and dialed in > sucessfully, and established a ppp connection. The FreeBSD box allocated > him an address of 192.168.x.x (correctly) but would then not allow him to > access anything apart from the local machine (by telnet). I think this is > because of netmask settings, but have not confirmed it yet. Netmask > settings should not be a problem however, as in a working configuration, > the BSD host should KNOW that the required address is "out that port" and > route it accordingly. After all, that's what routers do. 192.168.1.* (through 192.168.254.*) are class C ranges -- you should use a subnet mask of 255.255.255.0 (unless you intend subnet it even further -- which seems unnecessary). It is more likely a routing issue. You probably need to manually add entries to your routing table. > What are we doing wrong? or not done that we should have? (is there a > FAQ on all this somewhere? or a set of magic config files?) The address ranges that your talking about are listed in RFC 1597 (superceded by 1918? -- but there's nothing new in the newer versions). There are also other IANA reserved address blocks including 10.*.*.* and 172.16.*.* through 172.31.*.* (???). The firewalls FAQ has somethings to say about this. I don't know about the rest -- as I'm wrestling with some of this now. We can share our discoveries (off line, by phone or on the list -- it doesn't matter to me). Hopefully I'll have time to put some of this together and put it on my web site (www.starshine.org -- don't bother looking yet -- there's just a "placeholder" page there at the moment). > Best regards, Ross Wheeler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607162012.NAA00636>