[Openswan Users] Establishing a VPN connection using certificates, --id <IP Address> vs --id <DN>

[Paul Wouters]

On Mon, 1 Jun 2009, Marcos Hacker wrote:

> Ths issue seems to be using an ID of type ID_IPV4_ADDR. If we try the same connection using an ID of type ID_DER_ASN1_DN
> (specified on the Netgear/right) and specify rightid = DN, the connection establishes as expected without having the
> right's end certificate loaded on the left.
> 
> In other words, when the Netgear identifies itself with it's WAN IP Address, OpenSWAN cannot seem to find the public key
> unless that key is loaded locally and specified directly. If the Netgear identifies itself with it's DN, then no public
> key needs to be loaded locally, but the id field does still need to know about the DN of the Netgear (right).

Arguably, you've just described a misconfiguration that the Netgear allows, does not interoperate with Openswan.

> The add_x509_public_key function is always adding in the key.id.kind as type ID_DER_ASN1_DN.  I believe that the
> connection type is varying from machine to machine, depending on settings (ie IP Address Type or DN Type), however the
> key is always being added as ID_DER_ASN1_DN type. This makes the same_id function fail out.

It should.

> I would like to comment out the following code in an attempt to get OpenSWAN to continue on and connect with an ID type
> of <IP Address>.
> 
> Within /lib/libopenswan/id.c::same_id(const struct id *a, const struct id *b), this if statement checks ID Type of
> pointer a and pointer b.
> 
> if (a->kind != b->kind)
>     return FALSE;
>
> I do not know the repercussions of this code change within the OpenSWAN architecture.

That will cause havoc if you also have a PSK defined for that IP address. It will mix up RSA vs PSK modes.

I'd have to think about what we can do to allow this case to work, without breaking anything
else. But you'll run into other issues too. If they propose based on ID_IPV4_ADDR. instead of
ID_DER_ASN1_DN, then for instance we will also not send out any CERT payloads.

Paul