ietf
[Top] [All Lists]

RE: Stupid NAT tricks and how to stop them.

2006-04-05 12:57:55


--On Wednesday, 05 April, 2006 11:23 -0700 Michel Py
<michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> wrote:

John C Klensin wrote:
It is simply not possible to configure those devices
to support use of static public addresses for hosts
on the LAN side.

First, this is totally false, see below. Second, if you want
to use public IPs on the LAN side you just have to plug your
hosts directly in the back of the {DSL|whatever} modem. Or use
the firewall of your choice.

Michel, "spreading disinformation" is a rather strong claim; not
one I would choose to make without actually examining the
devices and their manuals, not just the marketing descriptions
you cite below.   That said, I did somewhat oversimplify the
problem I described.  More detail, and a pair of partial product
reviews, follows below.  If I owe the vendors an apology, I will
apologize, but I will do so only in the presence of either
vendor documentation of how to do what is needed (user manual,
knowledge base article, or the equivalent) or a user-level
description of how to do it that the vendors will support.  See
below.

This situation would somewhat contaminate the results
of the survey you suggest above.

Not at all, see above. Plus, read below also.

It is worth noting in this context that many of the Router
products that are sold for SOHO use (including the high-end
products from the first two vendors listed above) (Linksys,
Netgear) do not provide any support for multiple static
addresses except via one-to-one NAT.

This is simply NOT true. Large numbers of SOHO "routers" can
operate with or without NAT and yes including the high-end
products from the first two vendors listed above.

Linksys RV042: http://tinyurl.com/zf7o8
Netgear FVG318:
http://www.netgear.com/products/details/FVG318.php And this is
the norm.

Our experience differs, but this is not disinformation.  I'm
running an RV082 (the 042's bigger and more capable sibling)
here and consigned an FVG318 to the parts closet before getting
the RF082.    In both cases, I bought the products at retail and
struggled for some weeks, reading manuals and using the vendor's
customer support mechanisms and, in the RV082 case, taking
advantage of some additional support resources before reaching
the conclusions that I reached.

At least part of the problem are some constraints that, as a
simplification, I didn't mention.  The two most recent ISPs I've
dealt with personally, and two more I've deal with on behalf of
friends I was trying to set up, all insist on owning control of
the front-end CPE "modem"/ "router" equipment.  They do not
permit (by Ts&Cs, password control, etc.) the customer to
reconfigure that equipment to, e.g., operate it in bridge mode.
The number of static addresses available or in use is quite
small, typically a /28 or even a /29.  Finally, I need a device
with the ability to specify port priorities and to supply some
firewall capability.

One implication of this is that there is a little problem of
router co-existence: the customer-supplied device has to be
plugged into the LAN side of the ISP-supplied device, using one
of those static addresses as its WAN-side but supplying the
others to devices on the actual LAN.  In principle, it ought to
be possible to do that by setting up static routes, but (i)
neither vendor was able to specify how to do it and (ii) some,
if not all, of the ISPs configure their interface devices to
require that different addresses appear on the different ports
they supply.

For both of these vendors "can use static addresses" in
marketing literature apparently mean that one can use a static
address on its WAN side and can turn DHCP off, or run DHCP with
MAC-mapped addresses, on the LAN side.  Both support those
capabilities; the problem is where the addresses come from.
Actual experience with trying to set the devices up with a
static /29 pool of public addresses used on the LAN side of the
device and with the same pool presented to and used from the
public Internet were unsuccessful.

Disclaimer about the Netgear box: I haven't tried to use it with
static, public addresses for well over a year.  Perhaps new
firmware and documentation has been released and it has been
changed to better support these functions.  I doubt it somehow,
but perhaps.

In the case of Netgear, there is not a hint in any of the
documentation, or in their knowledge base as of a year or so
ago, that use of public addresses is possible.  After an
extended discussion with their technical support operation (and
an escalation or two), I was told that the device would not
support what I needed (i.e., public addresses on the LAN
identical to the public addresses by which the Internet saw
those hosts, with no NAT function of any sort) and that, if I
could trick it into doing what I was asking for, they would not
support it.   That led to a discussion about how they could
claim support for static, public, addresses, but that discussion
didn't lead anywhere.

In the case of the Linksys device, the documentation is fairly
clear that the address space on the WAN-side needed to be
disjoint from the address space on the LAN-side.  The
configuration software is even more clear: the options are
one-one NAT or some other device.  There has been a fairly
recent software release that permits the mapping between
internal (LAN) addresses and external (public) ones to be
exposed sufficiently on the LAN side that, if a device is
referenced from the LAN by its public address, the right things
will happen (after having the device running for slightly over
three months that way, I'm not convinced it works in all cases,
but the intent is clear).  But the LAN-side addresses are
required to be either private or user-supplied public ones, but
not the addresses that are presented on the public side of the
device.  In any event, that works, but it works by virtue of 1-1
NAT.

A solution to this is that either the ISP-supplied CPE or the
internal router device operate in bridge mode.  But the ISP
devices often cannot be configured into that mode (see above,
with no claim about other ISPs and what they will or will not
permit), and neither the Netgear nor the Linksys boxes can be
operated as bridges.  

The one I use right now:
http://www.broadxent.com/products/8120.asp

I have no firsthand experience with this device.

and many more:
http://www.sonicwall.com/totalsecure/ts10.html

As far as I know, all of the SonicWall devices, including one I
have used actively for some years, will operate as bridges.  But
they are significantly more expensive than the devices cited
above, are intended to be used on a monthly subscription basis,
and, at least in the units I have used, offer only the weakest
capabilities for e.g., port prioritization.

http://www.netopia.com/equipment/routers/routers_models.html
I have seen some of the speedstreams too and they all had an
option to run with or without NAT. Many of them also have the
option to have a "bridge" mode allowing the customer to
provide their own router/firewall solution.

It is that "bridge" mode that is critical.  As I indicated
above, neither the Linksys nor the Netgear devices provide it.
The SonicWall does, but raises other, unrelated, issues.  I
carefully did not address any devices I haven't actually used.
That leaves us in a state in which it is necessary to handle
static public IP addresses by either 

        * running the ISP's interface device in bridge mode,
        which many (although perhaps not all) ISPs prohibit
        
        * running the router devices as one-one NATs

which is what my note indicated.

Please stop spreading disinformation. The proof is in the
pudding, just click on the links above. Maybe actually looking
at what's out there would help too.

See above.

     john




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf