[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 23:11 -0500, Michael H. Warfield wrote: 
> 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.

Well, so much for THAT theory.  If I set leftprotoport or rightprotoport
to ANYTHING, it won't load the conn and gives me no error in the logs
what so ever and the conn does not show up in ipsec auto --status at
all.  I tried setting rightprotoport=17/500 and leftprotoport=17/500 and
17/4500 and even the example from the man page of 17/1701 for l2tp and
the connection just no longer appears.  No error, no connection.
Sigh...

> 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/20100221/a32321c3/attachment.bin