--- Joe Maimon <jmaimon at ttec.com> wrote:
David Barak wrote:
--- Joe Maimon <jmaimon at ttec.com> wrote:
Hello Rodney,
At first cut, I am trying to effect a seperation
between the interfaces
which need (overload)natting done and the ones
that
dont. Exactly what
that will buy me in terms of nat problems,
performance or logical
correctness I am not quite certain yet.
As is currently, If it turn nat on for some
interfaces on the router, I
have to turn it on for all so that others dont see
rfc1918 that they
would not be expecting. Such is only proper.
Why nat? Well some customers like to link up a few
of their sites with
the cheapest CPE possible which supports the
simplest network possible.
A Linksys router is $40, and it runs NAT. I can't
really imagine that that's a serious cost barrier
for
CPE.
In these case the customers do not want to run nat
because they want to
have multiple sites communicate with eachother with
no fuss or muss, on
their private IP space, be firewalled from everyone
else and have
internet access as well.
Do you see the irony of "be firewalled from everyone
else" and "have Internet access as well" in the same
product?
You will say, have the customer do ipsec......maybe
for new ones.
Marketing likes to sell this as a product. IOW
managed wan/internet
services.
Not necessarily IPSec, although that's a good idea if
they're serious about security. Rather, I would still
say that NAT belongs on CPE, not on a provider device.
How about this:
build the customers a 2547bis network, and make one of
the spokes the inside address of the firewall segment?
9 messages in net.nether.puck.cisco-nsp[c-nsp] Re: Interfacing between VRF a...
