[Openswan dev] Multiple clients with same ID behind NAT

Venkat Yekkirala vyekkirala at TrustedCS.com
Tue Oct 2 13:01:31 EDT 2007


> -----Original Message-----
> From: Paul Wouters [mailto:paul at xelerance.com]
> Sent: Tuesday, October 02, 2007 11:06 AM
> To: Venkat Yekkirala
> Cc: dev at openswan.org
> Subject: Re: [Openswan dev] Multiple clients with same ID behind NAT
> 
> 
> On Tue, 2 Oct 2007, Venkat Yekkirala wrote:
> 
> > I have a setup where all the clients behind a NAT share
> > the same ID and cert.
> 
> That's wrong. You *might* (very unlikely) get away with it
> using uniqueids=no in config setup.

I do have uniqueids=no in config setup.

> 
> > The VPN Gateway on the other end
> > has a public IP and X.509 certs are in use.
> 
> That certificate is different?

Yes. All clients share the same cert but the VPN Gateway on the
other end uses a different cert :)

> 
> > I am running into problems with running more than
> > one client behind NAT (dynamic IP). When I start
> > multiple clients at the same time, only one completes.
> 
> That's because they all have the same ID, they ARE the same
> client, and without uniqueids=no, openswan will disconnect
> the "old session" if a client reconnects from elsewhere.
> 
> Your setup is broken. Any single client compromise would lead
> to all clients being compromised. One untrusted client can
> lead to compromise of all trusted clients. Giving everyone
> the same key is just not a real security solution.

I agree this would be considered broken in the general case,
specifically in regard to authentication. But the session 
encryption would any way be done using a unique symmetric
session key (PFS) so a compromised client can't eavesdrop
nor do a man-in-the-middle correct?

The specific threat model at hand requires only an authenticated
and encrypted tunnel between any client and the gateway. It needn't
differentiate one client from the other for authentication purposes.

Now it seems to me if OpenSwan did use a different host pair for
each one of these connection instances (as differentiated by the NATed
IKE port of the client), find_phase1_state() would then have been able
to find the right phase1 SA. I can do a patch that does this and submit
it if you agree the host pair could be unique for each client.

Example:

Client				NAT					CURRENT HOSTPAIR ON GATEWAY

172.16.233.101 (500/4500)	10.1.10.100 (32700/32701)	10.1.10.160:500;10.1.10.100:500

172.16.233.102 (500/4500)	10.1.10.100 (32702/32703)	10.1.10.160:500;10.1.10.100:500

As can be seen, both instances use the same hostpair. But if we used a different host pair
for each client as in: 10.1.10.160:500;10.1.10.100:32701  and 10.1.10.160:500;10.1.10.100:32703
then find_phase1_state() will find the right SA, correct? Or am I wildly off-track here?


More information about the Dev mailing list