[RRG] NAT capabilities

[RJ Atkinson <rja@extremenetworks.com>]

Earlier Robin Whittle wrote:
% NAT doesn't give portability or multihoming.

This is provably wrong.

My employer's internal IP network has been using NA(P)T
for years, for many reasons -- including the address
portability and multi-homing capabilities that it provides.

As this type of deployment appears not to be obvious
to some, I'll try to sketch the way things work.  I doubt
we were the first deployment of this architecture.  I
believe this network architecture to be widely deployed
around the globe at present.

Basic Deployment Concept:
- All internal devices are numbered in private address space
  [RFC-1918].
- Policy says that only authorised devices should be reachable
  from initiating nodes outside the corporate internal network.
  There are relatively few of these; some live in a DMZ subnet.
- Policy says that only authorised application protocols are
  permitted.  Anything not authorised is blocked by the firewall.
- A NAPT+IPsec-VPN+Firewall box is deployed at each point
  where a segment of the corporate network touches the
  global Internet.  Some boundaries might have multiple
  such boxes that share session state among themselves.
  These boxes have at least one public IP address each,
  sometimes a box might have a handful of public IP addresses.
- All external traffic is processed by the firewall function.
  Authorised external traffic is then sent through to the
  inside via the NAPT function.  The inverse is performed
  for traffic originating inside and terminating outside.
- IPsec VPNs are used between such boxes to create secure
  internal connectivity among corporate sites.  These VPNs
  take traffic arriving on the red interface of the gateway
  box, put it into an IPsec tunnel, and send it out the
  black interface of the gateway for delivery to an equivalent
  remote gateway system (where the traffic is decrypted,
  removed from the tunnel, and forwarded to its destination).
- Remote offices or remote workers typically have one such box
  that has 1 public IP address (on its black interface).

Renumbering:
- Because only a handful of our devices have any public IP
  address(es), renumbering is practical.  IT typically brings
  up the new uplink first, configures that into the gateway
  boxes as appropriate, then deconfigures the defunct public
  IP addresses.
- Most often, the gateway boxes can learn their public IP
  address(es) by acting as a DHCP client on their black
  interface(es).  This makes things even easier.
- Internal systems never need to be touched when external
  connectivity changes.

Multi-Homing:
- Again, this is handled by the gateway boxes.  If there are
  multiple upstream providers, then each gateway typically
  gets at least one public IP for each upstream provider.
- As the total number of public IP addresses is tiny, IT
  says this is practical for them to undertake.

NAT operational problems:
- IT says that they don't have any real operational problems
  due to NAT/NAPT.  Only explicitly allowed applications are
  permitted through the firewall.  All of these work fine
  with NAT/NAPT (To use ftp, "passive mode" is required,
  but that is already widely deployed, so not an issue.)
- Some other organisations, having different policies,
  might have different conclusions about whether a NA(P)T
  approach is reasonable.

NOTE WELL:
  I am not suggesting that this is the only possible approach.
I am also not suggesting that everyone will like this approach.
It clearly does work well for a significant number of current
IPv4 deployments, however.

Yours,

Ran Atkinson
rja@extremenetworks.com




--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg