[strongSwan] decoupling server's leftid and server's certificate

[Robert Lee]

Hi,

I am looking for a way to configure the gateway moon to serve multiple
connections with a single certificate, but each connection should have its
own leftid (not the default moon.strongswan.org). A single client will
request different connections and the moon will find the corresponding
connection with the unique combination of <leftid=first_connection_id,
rightid=same_client_id> or <leftid=second_connection_id,
rightid=same_client_id>. For example:

conn %default
    leftcert=moonCert.pem       # moon will use this single certificate
    rightid=same_client_id        # same client will request the
connections below
conn connect_1
    leftid=first_connection_id       # same client will request this conn
using its rightid=first_connection_id
conn connect_2
    leftid=second_connection_id # same client will request this conn using
its rightid=second_connection_id

I noticed that, if the leftid is not moon.strongswan.org (as confirmed by
moon's certificate), then server will use the default 'C=CH, O=Linux
strongSwan, CN=moon.strongswan.org' as the leftid for this connection. The
client does the same thing by turning its rightid to the same default.
Since both server and client are strongswans, there is no problem
establishing the tunnel, but all connection lookups will fall onto the
first connection based on the same defaulted leftid and the same rightid.

How can we make the server decouple its leftid and its certificate as in
the sample ipsec.conf above?
Does this violate any specifications/standards?

Will the change cause further problems when server sends its reply with
IDENTITY, AUTH, and CERT to the client?
I guess the IDENTITY would be the configured leftid (first_connection_id,
etc), but not the defaulted strongswan, correct?
AUTH would still be coupled with the CERT (moonCert.pem for strongswan),
but would have nothing to do with the IENDITITY, correct?

Thank you!
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120924/004116a3/attachment.html>