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

[Paul Wouters]

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.

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

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

> 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 :)

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

Paul