Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!vixen.cso.uiuc.edu!howland.erols.net!cam-news-hub1.bbnplanet.com!news.mathworks.com!nntp.primenet.com!mr.net!uunet!in2.uu.net!nntp.wwwi.com!ddsw1!news.mcs.net!not-for-mail From: les@MCS.COM (Leslie Mikesell) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: IP Masqerading? Date: 19 Aug 1996 00:17:15 -0500 Organization: /usr/lib/news/organi[sz]ation Lines: 92 Message-ID: <4v8tcr$8ei@Mercury.mcs.com> References: <jfortes-1307951117380001@10.0.2.15> <32127AB2.21876B97@lambert.org> <4v0lsb$6uv@cronkite.cisco.com> <32151AD0.699795F7@lambert.org> NNTP-Posting-Host: mercury.mcs.com In article <32151AD0.699795F7@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >] In other words, if your application doesn't support socks, you >] can't use it. So, NAT is more general than Socks. > >This is technically true, but misleading. > >Typical use of NAT (at least in the Linux sense, and in the >sense where you would require direct translation) does not >involve a firewall. It involves: > >1) Someone who doesn't want to pay their ISP for more than > one address. And doesn't want inbound connections to more than one address, perhaps not even that. These people would need a firewall if they had full routing enabled. >2) Someone who doesn't want to pay their ISP for packet > forwarding. Because they have no need for it and would have to do extra work to prevent it if they had it. >3) Someone who wants to run an MS OS which is not itself > SOCKS aware and is too lazy to install the SOCKS aware > WSOCK32.DLL The MS reference is gratituitous there. It applies equally to any binary distribution or embedded system where it is difficult, impossible or at least annoying to install socks awareness. >Basically, it's for lazy people or cheap people. Translation: practical people. >I have no problem with people being cheap, but they should admit >that that's what they're doing instead of trying to cloak it in >better robes. > >I have a problem with lazy people. But, since I don't want to >force my world view down everyone's throat (or more likely, I >simply can't 8-)), the least they can do is, once again, admit >it. Let's see, we can say it's cheaper and easier and since the nat capability typically comes with packet filtering in the same package, safer. Now what was the down side? >Given that there are typically better alternatives to NAT in all >but a few cases (*real* range translation, for instance), I will >pretty much put all NAT usage in the category "indiscriminate use". >8-). Better from what viewpoint? I thought we established that nat was cheaper and easier. >] |o RFC-1256 ICMP router discovery doesn't work through a >] | "masquerade". >] >] It doesn't work past a firewall, either, nor would you want it >] too. In essence, so what? > >Typical NAT usage is to overcome some specious economic setup, >and is not in the context of a firewall. If any of the RFC >arguments don't hold water, it would be my RFC-1919 argument >(which still holds water in the full "range translation" case). How many places using NAT would be comfortable with a non-firewalled internet connection if they understood the implications. >] |o RFC 1063 MTU discovery doesn't work through a "masquerade"; >] >] Uh, and why not? Even blind NAT will have no problem properly >] conveying the information for this option, > >Use of ICMP packets. I'd prefer to firewall ICMP if it didn't make people think the network was broken. >] Obviously, you have something of an axe to grind wrt. NAT > >My only axe is that it irks the bejesus out of my elegance >filter. 8-). If tcp were elegant, NAT would be too - or there would be no need for it. Les Mikesell les@mcs.com