Contivity VPN woes

Paul Moore pcmoore at engin.umich.edu
Wed Nov 20 06:29:48 EST 2002


> -----Original Message-----
> From: bscott at ntisys.com
> To: Greater NH Linux User Group
> Subject: Re: Contivity VPN woes
>
> {snip}
>
>   All X.509 does is eliminate manual distribution of the authentication
> keys.  In fact, AFAIK, X.509 exists outside of IPsec entirely.  I cannot see
> how X.509 would have any impact, positive or negative, on NAT interactions.

x.509 certificates sorta exist outside of ipsec, they exist in ike the protocol
which is used to negotiate ipsec sas and given the alternative of using a
pre-shared key (just a string value known by both ends) for authentication x.509
certificates have some benefits for nat'd connections, see below.

> NAT and IPsec don't get along in three major ways:

better make that four. :)

another problem that hasn't really been discussed here is ike, and speaking from
experience i would say the #1 (or a very close #2) reason for failed ipsec
connections is ike.  there are many reasons for this and most go beyond what we
care about in this case, but there is one case involving pre-shared keys and
nat'd connections that may be relevant here.

as i kinda alluded to earlier the two most popular methods of ike authentication
are x.509 certificates and pre-shared keys.  due in part to the nature of x.509
certificates and their verification they _should_ be immune to any nat mangling
that may take place which is why i would recommend them for use in nat'd
connections.  however, pre-shared keys may not fare as well depending on the ike
implementation.

this is caused by the fact that pre-shared keys have an identity attached to
them (certificates do as well, they are just inside the certificate and not ip
dependent) which in some, possibly the majority of the cases is the ip address
of the host.  this can cause problems when the nat box starts changing the
source address of the packet as it leaves your private net.

there could be some other issues involving ike-through-nat as well, this just
sprang to mind as i was reading your mail.

> Another approach is something called "NAT transversal", or "NAT-T".

fyi, unless i am mistaken while there may be some implementations that claim
'nat-t' support i do not believe this is yet a standard, i think it is still in
draft status.

.... pcmoore at engin.umich.edu .... www.alumni.engin.umich.edu/~pcmoore ....




More information about the gnhlug-discuss mailing list