[Openswan dev] [Openswan Users] Trying to get Openswan working Ubuntu to Cisco ASA 5510

[Michael H. Warfield]

On Fri, 2010-03-12 at 00:32 -0500, Paul Wouters wrote: 
> On Thu, 11 Mar 2010, Michael H. Warfield wrote:
> 
> > Ok...  So...  Paul forwarded your message to the dev list so I'm cc'ing
> > the dev list on my reply to your original message...
> 
> The more people, the less we all have to find out on our own!
> 
> > But it got me drilling down in there and I found it deeper in
> > oakley_alg_makedb and the maxtrans parameter.  Seems to have been called
> > with only 3 values, -1, 0, and 1 from elsewhere.  It only checks for ==
> > 1 to limit to one proposal.  No idea what the different between -1 and 0
> > was suppose to have been.

> I would have to try and find some history on that too. It's likely post-dhr
> his code, though he might have an idea anyway.

Yeah, I was kinda eyeing that code thinking what I would like that
discrimination for and I couldn't come up with anything, so I really
don't know.  It's just in that one spot in out_sa that would be
different than the ag_init stuff.  Shrug...

> > So I added a value of 2 to mean multiple
> > proposals but only one DH group (and use the first DH group for that).
> > Then I changed the calls that called it with 1 to call it with 2.  In
> > that case, the code then complains if it encounters a DH group that
> > differs from the initial group and skips that proposal and continues on.
> > That seems to have done the trick

> That looks good!

> > (once I disarmed one passert booby
> > trap in init_am_st_oakley).

> It would be best to change the passert to allow the new case as well and
> still try to passert on unknown/wrong things. (I did not look at the code
> yet, it might be that this particular passert would no longer serve a use)

> >  I can now specify 8 proposals (the only 8
> > from vpnc that match what OpenSWAN will support of the 24 that vpnc
> > supports)

> Which do we not support? Are those 1des and/or modp768 proposals? Or are
> those proposals we should support?

Correct.  Couple of 1des and a couple of "reserved" encryptions.  But
they were all mod1024.  That made it 12.  Then there were a matching set
of "PSK" to go with them.  Not sure what that was...

This is the complete set of 24 proposals from vpnc

  0 aes256-sha1-mod1024     XAUTHInitPreShared
  1 aes256-md5-mod1024      XAUTHInitPreShared
  2 aes192-sha1-mod1024     XAUTHInitPreShared
  3 aes192-md5-mod1024      XAUTHInitPreShared
* 4 aes128-sha1-mod1024     XAUTHInitPreShared
  5 aes128-md5-mod1024      XAUTHInitPreShared
  6 3des-sha1-mod1024       XAUTHInitPreShared
  7 3des-md5-mod1024        XAUTHInitPreShared
  8 des-sha1-mod1024        XAUTHInitPreShared
  9 des-md5-mod1024         XAUTHInitPreShared
10 RESERVED-sha1-mod1024   XAUTHInitPreShared
11 RESERVED-md5-mod1024    XAUTHInitPreShared
12 aes256-sha1-mod1024     PSK
13 aes256-md5-mod1024      PSK
14 aes192-sha1-mod1024     PSK
15 aes192-md5-mod1024      PSK
16 aes128-sha1-mod1024     PSK
17 aes128-md5-mod1024      PSK
18 3des-sha1-mod1024       PSK
19 3des-md5-mod1024        PSK
20 des-sha1-mod1024        PSK
21 des-md5-mod1024         PSK
22 RESERVED-sha1-mod1024   PSK
23 RESERVED-md5-mod1024    PSK

The "*" was the one the server accepted...

> > The code point you pointed to DOES fire if (and only if) there is NO
> > ike= specification provided.  Ok...  That's bad, but not that bad.
> > Particularly since the man pages even mentions an example of
> > ike=mod1024.  Wow...  That would do exactly what I want!  Wild card
> > everything else and give me every combination with that single DH group.
> > Trouble is THAT doesn't work.  The parser is not behaving as documented.

> There have been some parser changes between 2.4.x and 2.6.x. I also checked
> using ike=;modp1024 but that failed too. This should be fixed in libipsecconf
> to be allow ike=modp1024.

> > In fact, none of the remarks and examples of leaving something off and
> > defaulting works (other that the DH group).  It spits all sorts of
> > errors about unexpected characters and incorrect values if I don't fully
> > specify an exact and complete proposal specification (with the exception
> > that I can leave of the DH group which is exactly what I want to
> > specify...).  Sigh...  So, if I explicitly specify all 8 proposals
> > individually, it works like a charm.  Kind of a pain though.  This is
> > what it looks like:

> You can leave out things, but the parser now assumes that IF you specify
> a modp group, you also specify hash and cipher. There were reasons in the
> past, mostly based on "the defaults allow all safe combo's, so if you want
> something specific, you might as well specify it all".

> So currently ike=aes works, but ike=sha1 or ike=modp1024 does not. Ideally,
> that would be fixed.

Cool.

> > Works but not exactly what I was after.  I'm going to look at main mode
> > and see how it handles the case of no ike specification but we really
> > could use the ike=mod1024 feature working.  It will be ugly to let the
> > make_db weed out all the proposals with the alternate DH groups with no
> > ike specification...  But, now, that's in an entirely DIFFERENT stretch
> > of code from all this.  Now it's back in the parser...

> I'd say that's prob easier then the proposal code :)

Before, I would have agreed.  Now having done it, this was a snap.  I
really hope you're right.  That must mean it'll be a walk in the park
for you.

> > That patch is attached here for this.  This makes multiple proposals in
> > aggressive mode work for me, even if it does make the config a bit ugly.
> >
> > Diff's are against 2.6.24 release code.  I can rebase if desired.

> I have not yet looked at it, but will try to merge it in tomorrow.

Very good.

> Paul

Many thanks!

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/dev/attachments/20100312/c1bb2ff3/attachment-0001.bin