[c-nsp] dynamic crypto maps and multiple endpoints?

Luan Nguyen luan.nguyen at mci.com
Fri Apr 22 00:01:54 EDT 2005


Hi,
You could only have one pre-share key for a peer address, it will cry like"
A pre-shared key for address mask 0.0.0.0 0.0.0.0 already exists".  So you
could only have" crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0" for the
hub.
Basically, you would only have to configure this for the hub:"
crypto isakmp policy 1
  hash md5
  authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
crypto ipsec transform-set rtpset esp-des esp-md5-hmac
crypto dynamic-map rtpmap 10
  set transform-set rtpset
crypto map rtptrans 10 ipsec-isakmp dynamic rtpmap
"
Since your hub doesn't know the addresses of the spokes, the spokes will be
the ones who initiate the connection.  If the hub is able to independently
create the same hash using its preshared key, it knows that both parties
must share the same secret, thus authenticating the other party.
A dynamic crypto map entry is essentially a crypto map entry without all the
parameters configured. It acts as a policy template where the missing
parameters are later dynamically configured (as the result of an IPSEC
negotiation) to match a remote peer's requirements. This allows remote peers
to exchange IPSEC traffic with the router even if the router does not have a
crypto map entry specifically configured to meet all of the remote peer's
requirements.  If the hub router accepts the peer's request, at the point
that it installs the new IPSEC security associations it also installs a
temporary crypto map entry. This entry is filled in with the results of the
negotiation. At this point, the router performs normal processing, using
this temporary crypto map entry as a normal entry, even requesting new
security associations if the current ones are expiring (based upon the
policy specified in the temporary crypto map entry). Once the flow expires
(that is, all of the corresponding security associations expire), the
temporary crypto map entry is then removed.  For static crypto map entries,
if outbound traffic matches a permit statement in an access list and the
corresponding SA is not yet established, the router will initiate new SAs
with the remote peer. In the case of dynamic crypto map entries, if no SA
existed, the traffic would simply be dropped (because dynamic crypto maps
are not used for initiating new SAs.
Hope that help a little.

Luan




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gert Doering
Sent: Thursday, April 21, 2005 5:23 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] dynamic crypto maps and multiple endpoints?

Hi,

I've today inherited an "interesting" problem in a customer VPN, and
before I go wrecking their setup tomorrow, I'd like to collect some
wisdom.

The problem part of the setup can be reduced to:

  - IPSEC VPN
  - hub-and-spoke
  - two spoke routers with dynamic IP addresses

if I look at

http://www.cisco.com/en/US/customer/tech/tk583/tk372/technologies_configurat
ion_example09186a0080093f86.shtml

the setup for a single "dynamic IP" spoke router is fairly trivial.

What I'm wondering now is: how do I configure this for two spoke
routers?  Will this work (based on the example above):


crypto isakmp policy 1
  hash md5
  authentication pre-share

! this is the key for the first spoke router
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
! this is the key for the second spoke router
crypto isakmp key OtherCisco address 0.0.0.0 0.0.0.0

crypto ipsec transform-set rtpset esp-des esp-md5-hmac

! this is for the first spoke (ACL 115 defines acceptable SA proxy values)
crypto dynamic-map rtpmap 10
  set transform-set rtpset
  match address 115

! this is for the second spoke (ACL 116 defines SA proxies)
crypto dynamic-map rtpmap 20
  set transform-set rtpset
  match address 116

!
crypto map rtptrans 10 ipsec-isakmp dynamic rtpmap

will that work? 

How does the router match incoming IKE requests to isakmp keys?  Will
it just try decrypting the IKE packets with both pre-shared keys, until
it gets a match?

How will it match the crypto map ACLs?  Just walk through the 
"dynamic map rtpmap" until it finds one where the ACL matches the
SA proxy in the phase 2 proposal?

thanks...

gert

PS: I've already told the customer that the most reasonable way to get 
this fixed is to get a static IP on the spoke sites.  But they are willing 
to pay serious money to fix the mess, instead of paying a little bit of 
money to get a static IP, and not cause a mess...
-- 
USENET is *not* the non-clickable part of WWW!
 
//www.muc.de/~gert/
Gert Doering - Munich, Germany
gert at greenie.muc.de
fax: +49-89-35655025
gert at net.informatik.tu-muenchen.de
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list