Breaking Stuff by Fixing NAT

We have some dial-up-like customers behind a device doing the dreaded
Network Address Translation (NAT). We are doing one-to-one
NAT. Customers get PPP connections with 10/8 addresses. The NAT is
done far down stream from our end of the point-to-point connnection at
the border with our ISP. Do not ask me why it was done that way. The
network engineers want to discontinue doing NAT. From our point of
view, NAT doesn't provide any benefits (it did take a while to get it
to sink in that it provides no security, and we do need to add some
BGP complexity since before packets could get NATed at any egress
point and find their way back). NAT only created continuous
headaches.

But there are still management reservations, the only reservation we
do not have a good answer for is the (arbitrary) claim that turning
off NAT may break stuff for customers who depend on it. Now we have
customers that do some pretty messed up stuff, and everybody knows
about various commercial apps that do really, really messed up stuff,
but none of us can think of anything that turning NAT off will
break. But perhaps all of our minds are just too cluttered with all of
the weird stuff that turning off NAT will allow to _work._

Has anyone here been in a similar situation? Did turning off NAT break
anything? Is anyone aware of or can think of anything that turning off
NAT might break? (Ignore the fact any customers connected during the
actual change may have service intrupted. I am only worried about
something that doesn't work next time they dial-up after the change.)

Thanks.

Crist J. Clark wrote:

But there are still management reservations, the only reservation we
do not have a good answer for is the (arbitrary) claim that turning
off NAT may break stuff for customers who depend on it. Now we have
customers that do some pretty messed up stuff, and everybody knows
about various commercial apps that do really, really messed up stuff,
but none of us can think of anything that turning NAT off will
break. But perhaps all of our minds are just too cluttered with all of
the weird stuff that turning off NAT will allow to _work._

I have to admit a certain amount of amusement when I read this.

In general you should be okay. The things that could break are likely those things that have IP addresses hardcoded. None of the following checks is any different than what you would do to renumber a network.

So, check your access lists on your routers, check any UNIX configuration files, as well as any SSL certificates that were somehow gotten with 10/8 addresses. Also, if you do H.323, check your gateway configurations. Users that make use of personal firewalls may have some minor complications along these same lines, particularly if servers are changing addresses.

The one change that you should be mindful of is this: if the company *was* relying in some way on security through obscurity, you may need to add a few additional protections, particularly if you want to prevent peer-to-peer access, such as Gnutella. Make sure that you have a real firewall in place, as you should have before :wink:

Regards,

Eliot

If the users have been getting a static address in the 10/8 range, they may
have it hardcoded someplace. If they've been getting their address/netmask/
DNS/etc via DHCP, then they'd already have discovered it breaks when they
hardcode it since the next time they connect they'll be up a creek.

> Has anyone here been in a similar situation? Did turning off NAT break
> anything? Is anyone aware of or can think of anything that turning off
> NAT might break? (Ignore the fact any customers connected during the

If the users have been getting a static address in the 10/8 range, they may
have it hardcoded someplace. If they've been getting their address/netmask/
DNS/etc via DHCP, then they'd already have discovered it breaks when they
hardcode it since the next time they connect they'll be up a creek.

As I stated in the original mail this is a dial-up-type service. The
connections are serial using PPP. The addresses are assigned within
PPP and are dynamic. They could get a different one within the block
every time they connect. Due to the nature of the service, we know for
sure that customers do not maintain always-on or almost always-on
connections.

Maybe a little diagram is in order,

[Customer]-----["Modem"]---{OurNet}---[NATing Router]---{Internet}
          ^ PPP ^
          > >
          > >
   10.100.100.0/24 AAA.BBB.CCC.0/24

The NATing Router does one-to-one NAT. It is _not_ a firewall. Once an
association between, say, 10.100.100.10 <-> AAA.BBB.CCC.10 is
established by an outgoing packet, you _can_ send arbitrary datagrams
back to AAA.BBB.CCC.10 and they get to 10.100.100.10. (The last octet
does not necessarily match up like that, however). There is _really_
no security benefit to the NAT.

This is what we are moving to,

[Customer]-----["Modem"]---{OurNet}---[Router]---{Internet}
          ^ PPP
          >
          >
   AAA.BBB.CCC.0/24

(In actuality it's a little more complicated with multiple "modem"
banks and multiple egress points to the Internet.) So as far as the
_outside_ world is concerned, the addresses look the same. So, say
someone has firewall rules allowing our customers some special access
as they come across the Internet. This will _not_ break. The customers
still will have the same source address.

The thing we just know is that if we stand up in front of the upper
management and say, "There is no way this can possibly break
_anything,_" there will have been some brilliant idiot out there who
found a way to set up some unmanned site with a configuration that
gets broken and some customer raises holy hell when they have to fly a
helicopter out to some remote location to get in a tech to fix it.

As I stated in the original mail this is a dial-up-type service. The
connections are serial using PPP. The addresses are assigned within
PPP and are dynamic. They could get a different one within the block

Ahh.. I missed the "and are dynamic" the first time around. I had the
mispleasure of running PPP with a static IP for quite some time due to
some software limitations...

The thing we just know is that if we stand up in front of the upper
management and say, "There is no way this can possibly break
_anything,_" there will have been some brilliant idiot out there who
found a way to set up some unmanned site with a configuration that
gets broken and some customer raises holy hell when they have to fly a
helicopter out to some remote location to get in a tech to fix it.

C>>K :slight_smile:

A *helicopter*? :wink:

One has to wonder which would flush out more brilliant idiots - making the
change without announcing it, or announcing it will happen the night of Dec
6/7, and actually doing it on the night of the 13/14. :wink:

I don't suppose you could get away with telling the brilliant idiots that
they just need to install the latest Microsoft hotfixes (though I'm sure
if you get to that point, they'll call back and ask why they wont install
on their Mac :wink:

/Valdis