A doubt on IPSEC & NAT

[Joel M Snyder]

>
> In addition, NAT may interfere with IPSec (both ESP and AH) if it prevents
> the two VPN gateways from successfully negotiating SAs using ISAKMP/IKE with
> certificates. X.509 certificates are signed by a trusted third party (called
> a Certificate Authority) in order to bind a user's or device's public key to
> some other identifying public characteristic. Once common identifying
> characteristic used for VPN gateway devices is external IP address.

The problem is worse than that.  There are about 10 different ways in
which the X.509 identity can be presented in the IKE authentication
payload.  IP address is one, but FQDNs are another, and if you bother to
check FQDNs (many vendors don't), then the identity can still fail.
Even if you use DN (type 9), which is fairly common among IPSEC vendors,
you may run afoul of subfields.

And this assumes you want to use certs and not something simple, like
PSS.

But NAT breaks things yet another way: assuming you are able to get
Phase 1 up with IKE, you still have to negotiate Quick Mode.  What IP
address is going to go into the identification payloads for the QM SA?
Each side has a different view of what the two IP addresses (or, more
typically, IP address and set of IP address ranges and subnets on the
gateway side) are to be protected with ESP.  If those fail consistency
checks or simply don't match, the QM SA might be established, but useless.

The short answer is that NAT is an evil thing and while it is possible
to get IPSEC going through NAT, it's a lot better to do it the other way around.

jms

VPN is sponsored by SecurityFocus.COM