RE: Where NAT disenfranchises the end-user ...
|> From: David Howe [mailto:DaveHowe@gmx.co.uk] |> Sent: Thursday, September 06, 2001 5:54 PM |> |> > Or more completely, they expect the network to be |> > transparent so that every port at the destination IP |> > address connects to the same machine, and there |> > is no operational restriction on which end initiates |> > the communication. Absolutely true. I'll take that clarification. |> which of course *is* possible for at least one machine per visible IP |> address - even if additional IPs are masqed behind it. if you are doing one:one NAT then why do NAT at all? if you are doing one:many then it won't work (broken).
* Roeland Meyer <rmeyer@mhsc.com> [20010906 18:16]:
if you are doing one:one NAT then why do NAT at all?
To ease a renumbering transition. I'll keep out of the rest of the thread.. -jr ---- Josh Richards <jrichard@{ geekresearch.com, cubicle.net }> [JTR38/JR539-ARIN] Geek Research, LLC - San Luis Obispo, CA - <URL:http://www.geekresearch.com/> KG6CYK - IP/Unix/telecom/knowledge/coffee/security/crypto/business/geek
Also sprach Roeland Meyer
|> which of course *is* possible for at least one machine per visible |> IP address - even if additional IPs are masqed behind it.
if you are doing one:one NAT then why do NAT at all? if you are doing one:many then it won't work (broken).
Even with one:many NAT you can pretty much get the same effect. You set up a default private IP address behind the NAT that any srcIP,dstIP,srcPort,dstPort combo that doesn't already have a mapping in the NAT box goes to. There's the possibilities of collisions here, but the chances are fairly low. Now, before anyone calls me a NAT apologist...I'm anything but that. There's no way on earth that I'd call this true Internet access, even for the default machine behind the NAT. Nor would I configure something like this as an ISP, disclosed or not (just ask Cincinnati Bell what I think of their Zoomtown Network setup and you'll find out how I feel about NAT! ;), but I do see that there are places - few, but they're there - for NAT. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
"Roeland Meyer" <rmeyer@mhsc.com> wrote:
Absolutely true. I'll take that clarification. Not one of mine, but more or less what I was thinking.
|> which of course *is* possible for at least one machine per visible IP |> address - even if additional IPs are masqed behind it. if you are doing one:one NAT then why do NAT at all? Plenty of reasons - you can have an entire 1918 network behind there, and only one or two machines "visible"; by using NAT rather than directly feeding those IP addresses to the machines involved, you simplify routing and separate admin of internal and external (if you need to fall back to a backup machine, you can have it running live in parallel, and one config change on the NAT will change the visible machine) It is pretty common practice for a company with a small (/24 say) allocation to static-NAT one or more to individual servers inside their lan, particuarly if those servers have functions like web proxy or email server.
if you are doing one:many then it won't work (broken). no, it *will* work for the one that is the default.
working from a one-IP allocation, let us assume a 1918 subnet on 192.168.123.x for the backend lan "web.mycompany.com" 192.168.123.5 "ftp.mycompany.com" 192.168.123.10 "webproxy.mycompany.com" 192.168.123.15 "Teleconferencing.mycompany.com" 192.168.123.20 "natdevice.mycompany.com" 192.168.123.25 Workpc1-->Workpc40 192.168.123.101 -->192.168.123.40 bearing in mind that "natdevice.mycompany.com" is also the external visible IP (via a separate interface) do suitably stateful Nat: for inbound port 80 - rewrite packet to web.mycompany.com for inbound port 25 - rewrite packet to ftp.mycompany.com for outbound from webproxy.mycompany.com or teleconferencing.mycompany.com - do stateful NAT for outbound from any other machine - ignore for inbound not covered by above - rewrite packet to Teleconferencing.mycompany.com with this setup, Teleconferencing.mycompany.com will appear to the internet to be listening on whatever ports it chooses to support, and also appear to be doing a whole heap of other things that it really isn't. In practice, a company would probably want to spread out the IPs here a little and get a bigger allocation, but it *could* be done this way if it had to be.
participants (4)
-
David Howe -
Jeff Mcadams -
Josh Richards -
Roeland Meyer