From: Chad Marsh (chad@xxxxxx)
Date: Thu Aug 10 2000 - 15:26:40 GMT-3
I don't think the transform sets are the problem. As long as both sides have
at least one match (in this case ESP-DES), they should negotiate. It looks
like phase-1 is negotiating to completion, and phase-2 is where it breaks.
I think the problem is in the access-lists.
For one thing, Cisco doesn't recommend using the 'any' keyword when
specifying an access-list for crypto, however I don't think that's really
the problem either.
The access-lists must be exactly inverse, or mirror images of each other in
order to complete the phase-2 negotiation.
In this case, the access-lists are:
R5
access-list 105 permit tcp any any eq telnet
R6
access-list 106 permit tcp any any eq telnet
For them to be inverse, they would have to be:
access-list 105 permit tcp any any eq telnet
and
access-list 106 permit tcp any eq telnet any
Chad Marsh
CCIE# 5185
----- Original Message -----
From: "Alan Simpkins" <alan_simpkins@yahoo.com>
To: "Kenny Sallee" <mischa@worldshare.net>; <Padhu@steinroe.com>;
<ccielab@groupstudy.com>
Sent: Thursday, August 10, 2000 11:05 AM
Subject: Re: IPSEC / ISAKMP sample config
> If the crypto maps on each side agree on the transform
> set to be used having multiple ones configured should
> not be a problem as they are specified in the crypto
> map. After re-reading your your reply I think we are
> stating the same thing in a differnet manner.
>
>
> --- Kenny Sallee <mischa@worldshare.net> wrote:
> > I don't think the peers will negotiate the transform
> > set. If that were
> > true, IPSec would be easier to hack. From my
> > experience, if the transform
> > sets don't match, phase 2 does not complete. As I
> > understand it, if the
> > IPSec endpoints can't determine which algorithm's to
> > use (esp, ah, des,
> > 3des) then they won't talk....Also, if you read the
> > output below from CCO:
> >
> > . The transform set defined in the
> > > crypto map entry will be used in the IPSec
> > security
> > > association negotiation to protect the data flows
> > > specified by that crypto map entry's access list.
> >
> > That itself says the crypto map will only use the
> > specified transform
> > set....That's how I read it anyway..
> >
> > Kenny
> >
> >
> > ----- Original Message -----
> > From: "Alan Simpkins" <alan_simpkins@yahoo.com>
> > To: "Kenny Sallee" <mischa@worldshare.net>;
> > <Padhu@steinroe.com>;
> > <ccielab@groupstudy.com>
> > Sent: Thursday, August 10, 2000 7:52 AM
> > Subject: Re: IPSEC / ISAKMP sample config
> >
> >
> > > I may be wrong here but as I recall, the peers
> > need to
> > > be able to negotiate at least 1 transform set, I
> > do
> > > not think all of them have to match, but I believe
> > at
> > > least must. Some peers may support transform set
> > > others do not. see the follpwing blurb from CCO
> > docs:
> > >
> > > A transform set represents a certain combination
> > of
> > > security protocols and algorithms. During the
> > IPSec
> > > security association negotiation, the peers agree
> > to
> > > use a particular transform set for protecting a
> > > particular data flow.
> > >
> > > You can specify multiple transform sets, and then
> > > specify one or more of these transform sets in a
> > > crypto map entry. The transform set defined in the
> > > crypto map entry will be used in the IPSec
> > security
> > > association negotiation to protect the data flows
> > > specified by that crypto map entry's access list.
> > >
> > > During IPSec security association negotiations
> > with
> > > IKE, the peers search for a transform set that is
> > the
> > > same at both peers. When such a transform set is
> > > found, it is selected and will be applied to the
> > > protected traffic as part of both peers' IPSec
> > > security associations
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --- Kenny Sallee <mischa@worldshare.net> wrote:
> > > > First off your transform sets don't match:
> > > >
> > > >
> > > > crypto ipsec transform-set r5 ah-md5-hmac
> > esp-des
> > > >
> > > > crypto ipsec transform-set r6 esp-des
> > esp-md5-hmac
> > > >
> > > > These need to match for phase 2 to complete ( I
> > > > think it is anyway maybe
> > > > phase 1). It looked like from the debug that
> > phase
> > > > 1 completed ( pre-shared
> > > > keys were exchanged and matched ) but phase 2
> > did
> > > > not..
> > > >
> > > > Also, I think your ACL's are wrong. You need to
> > > > permit the return traffic
> > > > in both directions depending on the direction(s)
> > you
> > > > want to encrypt telnet.
> > > >
> > > > So for R5:
> > > >
> > > > access-list 105 permit tcp any any eq telnet log
> > > > access-list 105 permit tcp any eq 23 any gt 1023
> > > >
> > > > and the same on the other router
> > > >
> > > > Kenny
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: <Padhu@steinroe.com>
> > > > To: <ccielab@groupstudy.com>
> > > > Sent: Wednesday, August 09, 2000 10:53 AM
> > > > Subject: IPSEC / ISAKMP sample config
> > > >
> > > >
> > > > > I am trying this and it isnt working for me
> > ...My
> > > > first time.. so
> > > > obviously
> > > > > i am overlooking something..Can any one take a
> > > > look at the
> > > > > config and comment on it ? thanks.
> > > > >
> > > > > I have defined telnet to be the only traffic
> > > > interesting for encryption..
> > > > >
> > > > > Cheers,Padhu
> > > > >
> > > > > <<ipsec.TXT>> <<ipsecdebug.TXT>>
> > > > >
> > > >
> > > >
> > >
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:23 GMT-3