Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!iafrica.com!uct.ac.za!und.ac.za!peacenjoy.mikom.csir.co.za!news.uoregon.edu!hunter.premier.net!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: IP Masqerading?
Date: Wed, 14 Aug 1996 18:17:38 -0700
Organization: Me
Lines: 97
Message-ID: <32127AB2.21876B97@lambert.org>
References: <jfortes-1307951117380001@10.0.2.15> <320F6E48.1EF468BB@lambert.org> <4urdc4$87m@herald.concentric.net>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Daniel Ts'o wrote:
> For us uninformed, could someone please reconcile these statements:
>
> : Has IP masquerading ever been impllemented in FreeBSD?
>
>
> >Well, build the loadable kernel module that comes with
> >Darren Reed's IPFilter and you can have NAT ( == IP Masquerading ).
>
> :No. IP "masquerading" is not RFC compliant. This has been
> :discussed to death.
> :
> :FreeBSD does, however, support proxy services, which is what
> :IP "masquerading" claims to be.
> :
> :There is code in the current release of the firewall toolkit
> :to do this, and there is Sock5. Either one of these will let
> :you do what you (apparently) want to do, but in an RFC compliant
> :way.
The IPFilter NAT code and the sentence two above this one are
in agreement.
> Being uninformed, my impression is that proxying via the toolkit
> Socks is very application specific. It would be nice to have a more
> general solution. Isn't masquerading more general ?
No, it is not. It is invalid because it violates the follwoing RFC's:
o RFC-1919... "Classical versus Transparent IP Proxies".
Socks is a classical proxy; a socks client daemon using an
IP tunnel for traffic encapsulation on a transport is a
transparent proxy. "IP masquerading" is neither. Section
4.2.5 is especially applicable.
o RFC-1256 ICMP router discovery doesn't work through a
"masquerade".
o RFC 1063 MTU discovery doesn't work through a "masquerade";
(clearly, the MTU should be lower than for an ethernet for a
PPP based "masquerade server").
o RFC-1477 IDP touches on proxy requirements which seem to not
be met by "masquerading".
o RFC 1935 "Looking at Firewalls", paragraph 2. Using "IP
masquerading" would allow a client to supply outside
services.
o RFC 1272 requires that "proxy agents have to do their own
accounting for services, since the network cannot
distinguish on whose behalf they are acting.".
> Don't really want to arrange apps specific proxy servers or hack
> in Socks support into each Internet app (many/most of which one
> only gets in binary form)...
1) Socks5 -- that's Socks****5**** -- supports proxying without
modifying applications.
2) You can use NAT. Be aware that you are in violation of the
RFC's which you must implement to be allowed on the Internet
as a "good network citizen" if you enable some types of
packet forwarding.
3) Using a tunnel device and static route asignments for internal
networks, and a socks-using-daemon (which no one has written
yet because they would rather violate RFC's than really solve
the problem or get valid address assignments and route them),
it is possible to support "local net" encapsulation over the
tunnel device to implement RFC compliant transparent proxy
services.
4) If you need this for PPP, Charles Mott posted about this
earlier in this same news group.
PS: I do not appreciate seeing a posting sent to me in email
if it has not been labelled as such. In general, I will
ignore the email version for the public response if I know
something to be both mailed and posted. It is annoying to
have to edit comments made in email to remove "flame bait"
content for the absurdly over-sensitive usenet. I would
prefer it if you do not make me write multiple copies of
my thoughts in multiple venues.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.