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

[Michael H. Warfield]

On Sat, 2010-02-20 at 18:18 -0500, Paul Wouters wrote: 
> 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?

Maybe Hugh remembers me from the FreeSWAN days when I couldn't
contribute anything except hassle them (US / Canada ITAR / EAR
regulations days) with testing.  Hopefully he remembers this.  But it
looks like there are some other syntaxs in there including @# (Key ID
type ID_KEY_ID and hex encoded data) and @~ (Key ID type
ID_DER_ASN1_DN).  They must have been put in there for a reason.

> > ==
> >    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?

I think that comment about the '"' is merely a screw-up in the comments,
but I'm not entirely sure.  It may have, in the early FreeSWAN days been
intended to be a '"' but the changed it to square brackets and didn't
update the comments.  THAT'S where my money's at.  Knowing the history
of the FreeSWAN 1.x early days, it would NOT be the first time.  IAC,
that code don't look right.

I'm fairly thorough in testing the documented combinations.  If I use
"Fobar" it gives a type of "IPv4 address" data "Fubar".  If I use
"@Fubar" it gives me type "FQDN" data "Fubar".  Looking at that code,
that appears to be the only way to get the Key ID type right.

> > 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've followed the cold paths.  I have to get the key ID type = ID_KEY_ID
and I don't seen any other path.

> > 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.

Working on that now.  Looks like setting leftprotoport might do the
trick but I haven't tried it yet.  However, in this case, we are not
using the vpnc option of cisco-udp (port 10000).  We're using the vpnc
option of force-natt, which uses the standard 500/udp 4500/udp which is
what we want to be doing.  Nobody expects OpenSWAN to support 1000/udp
or the Cisco IPSec over TCP.  Just trying to get the stock and trade
working.

Let me know if you think of anything you want me to try and test while I
poke at this some more.

> Paul

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20100220/1c4ae8d2/attachment.bin