What's the deal with NAT?

[Biggerstaff, Craig]

> From: Biggerstaff, Craig [mailto:Craig.Biggerstaff at CSOCONLINE.COM]
> An IPSec "tunnel mode" VPN does its magic by completely
> encapsulating the
> outbound source packet, headers and all, in a new IP packet.
> The new IP
> packet's source address is the outbound address of the VPN
> device, and its
> destination address is the inbound address of the VPN device
> at the other
> end.  Using the IPSec ESP method, the packet contents (in
> this case, the
> original packet) are encrypted, and both encrypted contents
> and new headers
> are signed with a hash value appended to the packet.
>
> Why this bothers NAT is the last part:  a NAT device in the
> middle will
> rewrite the new source address with one of its own choosing.
> The VPN device
> at the other end will verify the integrity of the incoming packet by
> computing its own hash value, and will complain that the hash
> value appended
> to the received packet doesn't match.  The VPN device at the other end
> doesn't know about the NAT in the middle, so it assumes that
> the data has
> been altered for nefarious purposes.


Follow-up to my own message:  I misspoke.  (Thanks to Michel B. Nakhla for
pointing it out.)

What I wrote is true for IPSec *AH* signing, not ESP signing.  AH computes
the hash based on both the payload and the new headers.  ESP computes the
hash based only on the payload (in this case, the original source packet),
so it should not be affected by NAT (in theory).

On the other hand, NAT *would* interfere with IPSec (both ESP and AH) by
preventing two VPN gateways from successfully negotiating SAs using
ISAKMP/IKE with certificates.

In the most likely scenario, the two VPN gateways would exchange
certificates signed by a trusted third party (a certificate authority),
binding each gateway's identity to its IP address.  NAT would rewrite the
addresses during IKE negotiation.



-- Craig

VPN is sponsored by SecurityFocus.COM