Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Feb 1996 15:32:02 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        ejs@bfd.com (Eric J. Schwertfeger)
Cc:        ptroot@uswest.com, mc7953@mclink.it, questions@FreeBSD.org
Subject:   Re: IP Masquerading
Message-ID:  <199602052232.PAA00445@phaeton.artisoft.com>
In-Reply-To: <Pine.BSF.3.91.960205101350.9370A-100000@harlie.bfd.com> from "Eric J. Schwertfeger" at Feb 5, 96 10:31:31 am

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> 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.



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?199602052232.PAA00445>