1- to -1 NAT and IPsec Tunnels (fwd)

TC Wolsey twolsey at REALTECH.COM
Mon Dec 13 13:05:23 EST 1999


> Tina Bird <tbird at KUSPY.PHSX.UKANS.EDU> 12/10/99 04:05PM >>>
>This may have been touched upon, but I just wanted a clarification.
>
>Can you establish an IPsec (triple-DES) tunnel when using one-to-one NAT?

Maybe. Assuming that you are using IKE to negotiate the tunnel the security gateways must be able to bind the NAT'ed address of the remote gateway to the correct identity. Using quick mode for IKE negotiations may help if you are using certs for authentication because the gateway gets the cert (identity) of the peer before it has to produce the key material that authenticates that peer. 

AFAIK, NAT will always break AH communications, tunnel or transport mode, although the RFC does not necessarily forbid this arrangement. 

If your ESP tunnel can be established then the packets should sail happily through the NAT with no ill effects.

>
>I know NAT overload scheme disrupts the header information, and prohibits
>IPsec tunnels.

All NAT disrupts the network (IP) header information, NAT overload (or PAT, masquerade, etc..) mangle the transport headers as well, specifically the port numbers for TCP and UDP. Of course ESP and AH do not have ports to multiplex multiple datastreams to one IP address, they use SPIs in the AH/ESP header to do something similar. You can play with the port numbers for most TCP/UDP communications and the upper layer payload will still be usable. Play with the SPIs in a AH/ESP packet while it is in transit and the receiving end will either drop it on the floor (almost always) or decrypt it just to have it fail authentication (the chance of this very small).

Regards,

--tcw

VPN is sponsored by SecurityFocus.COM




More information about the VPN mailing list