From owner-freebsd-questions Mon Feb 5 14:35:07 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA01694 for questions-outgoing; Mon, 5 Feb 1996 14:35:07 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA01665 for ; Mon, 5 Feb 1996 14:34:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA00445; Mon, 5 Feb 1996 15:32:03 -0700 From: Terry Lambert Message-Id: <199602052232.PAA00445@phaeton.artisoft.com> Subject: Re: IP Masquerading To: ejs@bfd.com (Eric J. Schwertfeger) Date: Mon, 5 Feb 1996 15:32:02 -0700 (MST) Cc: ptroot@uswest.com, mc7953@mclink.it, questions@FreeBSD.org In-Reply-To: from "Eric J. Schwertfeger" at Feb 5, 96 10:31:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.org Precedence: bulk > Actually, this isn't what he's talking about. The Linux implementation > of IPFW includes some kernel mods that let a firewall translate > (masquerade) "outgoing" requests, so that the packets have the firewall's > IP address, and then retranslates the responses so that they get to the > correct machine/port. It's called "proxy". It's not "masquerading" because you can't set up incoming FTP requests (for instance) to one of the proxied machines. The "correct BSD way" of implementing this would be to provide a packet forwarding daemon that used the tunneling device to do it's thing. Linux's "masquerading" is a _hack_ to get around getting your ISP to route you correctly because you are silly enough to buy ISP services from someone who charges for router entries. Or because you are too cheap to acquire a subnet registration. There is *no way* to implement this type of thing and remain in strict compliance with the RFC's. > Basically, for WWW, Telnet, and passive FTP, this lets any application > pass through the firewall without knowing the firewall is there, the > firewalled workstations think of the firewall as just the default router. Using a local interface and tunneling on the "clients" to a "socks" connection to the firewall would be yet another alternate implementation: one that in fact would be nearly-legal, at least as long as all connections are outgoing. This has the advantage of working for active protocols without packet twiddling, since you can have the client assign sockets *after* the socks assignment on the server for the port grab. You *should* implement the local subnet as an unrouted network (one of the reserved subnets for doing exactly this) if you write the tunnel-to-socks daemon for the client machines. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.