[Openswan Users] Ipsec configuration Lucent VPN Gateway with OpenSwan or others (Lucent IPSec Client 9.2.0 in Windows XP)

[Paul Wouters]

On Sat, 20 Feb 2010, Michael H. Warfield wrote:

>> So, AFAICT, there seem to be two problems for me to solve here.  One is
>> to give the server a block of acceptable proposals from which it will
>> select one.  Two, I need to get that Key ID correct.
>
> Hmmm...  Not comfortable with just diving too deeply into that
> init_am_st_oakley stuff there in spdb_v1_struct.c even though that
> appears to be where we need to be building a set of proposals.  I
> understand that aggressive mode can not renegotiate and all but we can
> (obviously from the vpnc trace), at least, initiate with a list of them,
> like vpnc does, and it's up to the server to then pick one and only one.

Yes, so you have to at least get the DH group right on the first packet
you send. Openswan forced you to set a single proposal in those cases,
because AFAIK it could not send more then one in aggressive mode. I
guess I might be wrong and it can send multiple, as long as the DH group
for all of those is the same (and the size being used on that first packet)

> Ouch...  This does not look good.  If that Cisco is looking for my group
> name in the Identification Payload with a type of "KEY_ID", that's a
> problem.  I finally found that in lib/libopenswan/id.c around line 136
> in atooid().  So if the leftid begings @[ you're going to take the rest
> of that parameter as an ascii key id with type ID_KEY_ID conditionally
> removing the closing ']'.  Tried that.  Lookee there, I got the right
> KeyID but the wrong payload length.  It's off by 2 if the string ends
> with a ']' and off by one if not.  So it doesn't look like it's trimming
> anything when I add that ']'.  And that code just does not look right...

I have never seen a leftid/rightid syntax with [] in them. Perhaps Hugh
remembers if that syntax is used anywhere?

> ==
>    else if (*(src+1) == '[')
>    {
>        /* if there is a second specifier ([) on the line
>         * we interprete this as a text ID_KEY_ID, and we remove
>         * a trailing ", if there is one.
>         */
>        int len = strlen(src+2);
>
>        id->kind = ID_KEY_ID;
>        id->name.ptr = (unsigned char *)src+2;
>
>        if(src[len+2]==']')
>        {
>            src[len+2-1]='\0';
>            len--;
>        }
>        id->name.len = len;
>    }
> ==

I am not sure how removing a trailing '"' becomes removing a closing bracket.
I'd have to look at more context on the ID_KEY_ID case.
Are you sure you cannot use leftid=@somestring?

> Now wait a minute here...
>
> You're checking "src[len+2]" if it's a closing bracket and, if it is,
> NULLing the character before the bracket?  That doesn't look right and
> it doesn't appear to be working either.
>
> That "leftid=@[literal_key_id]" needs to be documented somewhere.

Once I know of a valid use, I can.....

> I couldn't find it in the documentation anywhere and I think that's going
> to be required for some configurations.  Maybe I'm being blind and
> overlooking it somewhere but I'm just not seeing it.  Should be in the
> man pages for ipsec.conf for leftid/rightid along with the rest of that
> archaine syntax supported in id.c.
>
> I still see a difference in that Identification payload that the one
> that works is specifying a "Protocol ID" of UDP and a "Port" of 500 and
> both are "Unused" in the case that fails.  That could account for
> remaining offset of the payload length.  I'm looking into getting that
> right now.

That might be related to cisco's non-standard use of UDP 10000. There is
some code in contrib/ that tries to deal with that.

Paul