From: Padhu@xxxxxxxxxxxx
Date: Thu Aug 10 2000 - 17:18:58 GMT-3
Multiple crypto maps to different peers right ?
also i see that under crypto map there is a option to specify local address
as the egress interface ..not sure why that would be reqd when the crypto
map itself is bound to the external interface..
Thanks again everyone . I will post a good working config once i get
everything working.
cheers,Padhu
-----Original Message-----
From: Kenny Sallee [mailto:mischa@worldshare.net]
Sent: Thursday, August 10, 2000 2:50 PM
To: Chad Marsh; Alan Simpkins; Padhu@steinroe.com;
ccielab@groupstudy.com
Subject: Re: IPSEC / ISAKMP sample config
The transform sets must match - straight from Cisco if you won't believe me:
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.
http://cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/ip
sec.htm#37434
Also from:
http://cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v51/config/ipsec.h
tm#xtocid2727412
In his transform sets, one specifies AH and the other ESP - if one or the
other is changed to ESP or AH it will work...Before data is encrypted, there
must be a succssful SA. If you do not complete phase 1 and phase 2 of IKE,
then you have no SA and no data will be encrypted regardless of the ACL's.
I was also wrong in an earlier post when I stated a crypto map could only
use one transform set...It can use multiple if applied to the crypto map
properly....
The ACL's are the second part of the problem.
Kenny
----- Original Message -----
From: "Chad Marsh" <chad@wa.net>
To: "Alan Simpkins" <alan_simpkins@yahoo.com>; "Kenny Sallee"
<mischa@worldshare.net>; <Padhu@steinroe.com>; <ccielab@groupstudy.com>
Sent: Thursday, August 10, 2000 11:26 AM
Subject: Re: IPSEC / ISAKMP sample config
> 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