A doubt on IPSEC & NAT

[Mike Forrester]

Actually, according to RFC 1918 it should be 172.16.0.0/12 (or 172.16/12)
which is the range from 172.16.0.0 to 172.31.255.255 (not 172.31.0.0).

http://www.cis.ohio-state.edu/htbin/rfc/rfc1918.html

----- Original Message -----
From: "married" <married at ziplip.com>
To: <VPN at SECURITYFOCUS.COM>
Sent: Monday, February 19, 2001 12:12 AM
Subject: Re: A doubt on IPSEC & NAT


> I think there are a couple of Cisco guys on this list.
> The private address range for class B is 172.16.0.0 to
> 172.31.0.0 and not only 172.16.0.0/24 as the page states. Probably just a
typo :-)
>
>
> > -----Original Message-----
> > From: Hugo Caye [mailto:Hugo at MICMAC.COM.BR]
> > Sent: Wednesday, February 14, 2001, 11:41 PM
> > To: VPN at SECURITYFOCUS.COM
> > Subject: Re: A doubt on IPSEC & NAT
> >
> > There is an interesting article titled "The Trouble with NAT" (by Lisa
> > Phifer) at:
> > <http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html>.
> >
> > Interesting because it give us a NAT's overview and explains why IPSec
> > and NAT shouldn't (and some times can) work.
> >
> > -----Original Message-----
> > From: Tina Bird [mailto:tbird at PRECISION-GUESSWORK.COM]
> > Sent: terça-feira, 13 de fevereiro de 2001 13: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
> >
> >
>
>
> *  Get free, secure online email at http://www.ziplip.com/  *
>
> VPN is sponsored by SecurityFocus.COM
>

VPN is sponsored by SecurityFocus.COM