A doubt on IPSEC & NAT

[Clement Dupuis]

Good day Tina,

I have seen multiple devices, more specifically DSL routers such as Nexland
that annonce DSL passthrough up to 100 clients.

Have you been using such a device and do they really allow IPSEC through

Thanks

Clement

> -----Original Message-----
> From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Tina
> Bird
> Sent: 13 fevrier, 2001 10:51
> To: VPN at SECURITYFOCUS.COM
> Subject: Re: A doubt on IPSEC & NAT
>
>
> NAT causes another problem with IKE, as some unfortunately
> souls trying to use VPN clients behind a firewall have
> discovered.
>
> If you're behind a machine doing address translation that
> also modifies the source port of your IKE packet, it won't
> be recognized by the IKE server.  For some reason that I've
> never understood, IKE expects source and destination port to
> be UDP 500, not just destination port like most of the other
> services out there.  So even if you managed to disable all
> the mechanisms which check for header consistency in the
> IPsec communications, you'd still be in trouble.
>
> I agree with Joel -- NAT is evil, but man!  given the large
> number of places I'm stuck using it, it would be nice to have
> a little more flexibility in the IPsec protocols.
>
> cheers -- tbird
>
> On Tue, 13 Feb 2001, Joel M Snyder wrote:
>
> > Date: Tue, 13 Feb 2001 09:13:33 -0700
> > From: Joel M Snyder <Joel.Snyder at OPUS1.COM>
> > To: VPN at SECURITYFOCUS.COM
> > Subject: Re: A doubt on IPSEC & NAT
> >
> > >
> > > 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
> >
>
> VPN:  http://kubarb.phsx.ukans.edu/~tbird/vpn.html
> life: http://kubarb.phsx.ukans.edu/~tbird
> work: http://www.counterpane.com
>
> VPN is sponsored by SecurityFocus.COM
>
>

VPN is sponsored by SecurityFocus.COM