[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC Security Gateways & NAT

At 12:56 07.06.01 +0100, you wrote:
>We've come up against a number of situations where the network service
>provider has used NAT and the customer wants to add IP security by adding
>Security Gateways between their networks and the service provider's access
>points.
>
>RFC2401 says that a Security Gateway must use tunnel mode unless it is
>acting as a host (eg management).  The negates the service provider's use of
>NAT by preventing it from translating client addresses - which in some cases
>overlap across across multiple private networks.
>
>Some vendors offer non-standard encryption modes - eg transport or
>proprietary - that do pass the IP (and even TCP/UDP) headers through in
>clear too.  This exposes the client IP address for NAT but means that the
>encryption end-points probably won't agree on the selectors for the security
>association - as they will see different addresses for the same client.
>
>Even assuming that the management issues associated with agreeing SAs
>(possibly with dynamic NAT) can be fixed, there appears to be a deeper
>issue:  Some protocols, most notably FTP, pass IP socket addresses at the
>application level.  These need to be translated by Application Level
>Gateways (ALGs).  However, once IP traffic has been enrypted, this
>information cannot be available to the ALG.
>
>This appears to imply that NAT, in general, must be performed before
>encryption.  This is at odds with the models that a number of service
>providers are trying to apply.  Are there any solutions to these problems?
>Or any papers detailing the sort of problems that occur when mixing NAT with
>IPSEC.
>
>Thanks,
>Chris
>

The consensus among IPsec vendors is ESPoUDP. You use tunnel mode,
and insert a UDP header in front of the ESP header. This is dead simple
and works with normal NAT boxes.

Problems and solutions:

- some NAT boxes drop fragmented UDP packets. You'll have to mess around
  with TCP segment sizes and/or encrypt fragments.

- The NAT box does not affect any protocols, like FTP, because it's modifying
  the "outer" IP header and an artifical UDP header.

- There might be address collisions. Two clients might be behind firewalls
and have
  the same address 192.168.98.6. Now they do quick mode to the same GW.
  Trouble ahead. You need some NAT here, be it at the GW or at the client,
  or private IP address by cfg-mode. Or something.

J–rn
References: