[Openswan Users] Ipsec configuration Lucent VPN Gateway with OpenSwan or others (Lucent IPSe

[srbarrios at gmail.com]

I do not understand why Michael write his question in this thread, with an  
specified problem for an specified gateway of Lucent-Alcatel and his client  
only for Windows, because his question is completely different with my  
question and the problem in this thread...
Anyway, thanks, but my problem is here, and I can't work in Linux.

El , "Michael H. Warfield" <mhw at wittsend.com> escribió:
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100221/b27cccd3/attachment-0001.html