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

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.

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.