On Fri, Nov 10, 2006 at 05:50:54AM +1100, nuffnough wrote:
> On 11/9/06, jared r r spiegel <[EMAIL PROTECTED]> wrote:
> >
> No Phase one. Just a packet to initiate, then a packet back to say that
> the far end doesn't like me. Debug on the other end indicated that when my
> end initiates, it does it with 128bit key length and a lifetime of one
> hour. Of course, I didn't have the brilliant idea of just setting my end
> up as passive, to make sure that the other end initiates. The required
> parameters fall within the ranges of the default AES-SHA config.
that reminds me of having the same kind of issue at times; where if i was
passive it would come up, but if i was the initiator, it would not.
that's part of the reason i chose to switch my configs to hard values
for the proposals, instead of that "want,min:max" syntax. i am very
glad that syntax is available, but as i didn't have to support a big
wide range of incoming clients piloted by knob twiddlers, i found it to
be a benefit to move to just "want" for the different params. got rid of
the 'sometimes works/sometimes doesn't/seems to matter if i init or am inited
upon' stuff.
> > without running it through isakmpd to parse it, and given that i'm a bit
> > rusty with isakmpd.conf, nothing jumps out at me.
>
>
> The real (prolly newbie) question that I think I need the answer to is:
> After I define a custom transform, am I still able to call the standard
> pre-defined transforms at the same time?
i bet $10 that yes, you can.
cannot say with certainty/hard reference examples at the moment, but
i believe that once isakmpd is running, the predefined transform jobbies
are no different to isakmpd than any you specify. perhaps it would
be an issue if you collided names for the transform/proto/suite, but
iirc you weren't doing that.
> I have about 20 other vpns with diverse encryption
> parameters. It would be moderately painful if I had to manually configure
> them all just to make this new one work.
>
>
> >Is there something I am missing about the structure of isakmpd.conf about
> >> the placement or reference of these new sections for lifetime and
> >> XX-AES-SHA?
> >
> > tbh i don't recall if order matters. here's a c/p of an isakmpd.conf
> > w/"custom" phase-1 and phase-2 i had running stable up until i switched
> > over to an ipsecctl-based scheme. ( we had our own X509 fqdn certs
> > from back in the certpatch days ). either end of the tunnel was OK
> > to initiate the negotiation, and the intent was for the tunnels to be
> > always up.
>
>
> Was this the only definition in your isakmpd.conf at the time..?
at one point i had added another peer who was using pre-shared keys
for phaseI; that peer had its own set of transform/proto/suites
defined in a similar fashion as the first ones, but little different
params ( longer lifetime, 128b key length on phaseI, whatever default
keylen is on phaseII, if that's even applicable there ).
i don't think i had one that was strictly one of the predefined transforms
at any point along side one using a "custom" transform... makes me wish
i had /etc in CVS a long long time ago.
> Just at the moment the guy configuring the other end has stepped it down to
> 128bit with a 1 hour timeout for me and we now get Phase-1 okay. This is a
> little unfortunate, because it means I can't run any of these
> ipsecadm/ipsecctl tests to get the output to give you so you can help me. I
> expect that he'll be back on deck in a few hours, and I will dump it in
> here then.
iow, either side can init the tunnel OK, doesn't matter who starts it?
if he did that and you still have the XX-phase-1-lifetime and XX-AES-SHA
thing in there, try doing the setting where you only specify the 128 and
3600; then see if the tunnel comes up with you init'ing as that again, then
do the lifetime to 86400 and restart, see if you still get tunnel with either
person init'ing. if that still works, bump the 128 up. i have this nagging
in the back of my head i can't get rid of that is telling me there's one of
the parameters where you think you're adjusting the cipher strength but
in reality the parameter ends up ignored and doesn't matter.
fwiw, when i've gotten to the point of sitting there banging my head
on a wall because 'no proposal chosen', and everything looks like it should
be working, it's 9/10 times been because of the damn lifetimes (mismatch).
( i think the other 1/10 has something to do with the key_length that for
some reason i can't stop thinking doesn't matter in either phaseI or
phaseII,
but i don't have the details on hand )
the bitch is when you don't know what the other side is using as a default,
but i think that -dDAblahbla one up there will catch those (expected/recv'd).
but yeah, if you both work ok at 128/3600, try 128/86400 first and then move
up the 128.
--
jared
