[Openswan Users] Ipsec configuration Lucent VPN Gateway with OpenSwan or others (Lucent IPSec Client 9.2.0 in Windows XP)
Michael H. Warfield
mhw at WittsEnd.com
Sat Feb 20 16:22:52 EST 2010
On Sat, 2010-02-20 at 13:18 -0500, Michael H. Warfield wrote:
> Paul,
>
> On Fri, 2010-02-19 at 22:46 -0500, Paul Wouters wrote:
> > On Fri, 19 Feb 2010, Oscar Barrios wrote:
> >
> > > conn Intranet
> > > ike=aes256-sha1-modp1024
> > > phase2alg=aes256-sha1
> > > aggrmode=no
> > > keyexchange=ike
> > > ikelifetime=24h
> > > auth=esp
> > > type=tunnel
> > > authby=secret
> > > left=192.168.2.100
> > > leftmodecfgclient=yes
> > > leftxauthclient=yes
> > > leftid="obarrios"
> > > right=62.xx.xx.xx
> > > rightmodecfgserver=yes
> > > rightxauthserver=yes
> > > modecfgpull=yes
> > > pfs=yes
> > > compress=yes
> > > auto=add
>
> > Usually, xauth is used with aggressive mode.
>
> > > 000 #2: "Intranet":500 STATE_MAIN_I1 (sent MI1, expecting MR1);
> > > EVENT_RETRANSMIT in 11s; nodpd; idle; import:admin initiate
>
> > Seeing that your first packet is rejected, your configuration likely
> > does not match what the other end is expecting.
>
> I'm having similar problems with a setup I'm trying to configure. I'm
> using Swan <-> Swan all over the place but now I'm in a circumstance
> where I'm trying to set up a configuration to a Cisco 3000 series
> concentrator and what I'm seeing seems to parallel a couple of requests
> for help I've seen on this list. They all have in common, aggressive
> mode and a fully specified ike proposal. That's just screaming to me
> that they are talking to a Cisco, or Cisco clone, of some sort at the
> other end.
>
> I may be in a unique position though. I HAVE got vpnc working to that
> same concentrator, so I can do parallel traces of what works and what
> doesn't. The main problem with vpnc is that it will only support one
> VPN up at a time, which is something some of us using that concentrator
> as one of our VPN's require.
>
> First and foremost, I see vpnc starting off with payload proposal
> containing 24 transform proposals. Right now OpenSWAN doesn't allow
> this. It complains about multiple proposals in aggressive mode and
> refuses to do it. Using a single proposal, I get a packet back saying
> "Message type: NO-PROPOSAL-CHOSEN (14)" (that's in wireshark). In the
> vpnc case, it sends 24 proposals over and the response comes back with
> 1. Even when I configure the Swan side to match the acceptable
> proposal, I still get back "Message type: NO-PROPOSAL-CHOSEN (14)".
>
> Another difference in the requests is the Identification Payload. In
> the working case, it's "ID Type: KEY_ID (11)" and "Protocol ID: UDP
> (17)". In the failing Swan case, it's "ID Type: FQDN (2)" and "Protocol
> ID: Unused". My group ID for the Cisco shows up under "Identification
> data:" in the failing case and in the vpnc case it Wireshark just says
> "Identification Data" without showing the data. Maybe I'm just not
> seeing it but I don't see how to get that key id set to anything other
> than an IP address or FQDN.
> 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.
But it looks like I should have a good single proposal now. So assuming
(which is never safe, I know) I have a single proposal in initiating
aggressive mode that matches the proposal the Cisco concentrator finds
acceptable in the vpnc case, I'm looking at the Identification payload,
which doesn't match the working case.
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...
==
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;
}
==
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. 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.
Mike
> Suggestions? I can make some limited traces available to you and work
> with you to drill into this deeper if this will help. I don't think
> dumping traces on the list would be helpful. I think this could help a
> lot of people if we could nail down what vpnc is doing and mimic it.
>
> > Paul
>
> Regards,
> Mike
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
--
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/ffa618d8/attachment-0001.bin
More information about the Users
mailing list