03-21-2007 03:39 AM
Hi!
We have a problem when enabling mode configuration. ESP tunnel setup works fine without, but when we enable mode configuration in the client, our Cisco router doesn't accept the IKE phase 2 proposal.
The error seems to be "no IPSEC cryptomap exists for local address 10.0.0.10", but we can't quite understand why. 10.0.0.10 is the router's outside address, not inside, and we do have a crypto map associated with the outside interface that is set to 10.0.0.10.
Another question is where we should put the "client configuration address respond
" - on the static or the dynamic crypto map?
Any input would be highly appreciated.
/Bjorn
03-21-2007 04:03 AM
03-21-2007 05:36 AM
Hi Bjorn,
Can you please add the command
crypto map SDM_CMAP_1 local-address FastEthernet4
Client configuration address respond command should be inserted for the dynamic VPN clients connection.
If it is for dynamic L2L tunnels, you do not need that command.
Rate this post, if it fixes your issues.
Thanks
Gilbert
03-21-2007 06:49 AM
Hi Gilbert.
Thank you for the suggestion. Unfortunately, adding the local-address changed nothing. If I understand correctly, this command is for when you have the same crypto map associated with multiple interfaces, but we do not in this case. We do not have a crypto map configured for the Vlan interface, but I assume we shouldn't.
I still don't understand the error message:
IPSEC(crypto_ipsec_process_proposal): no IPSEC cryptomap exists for local address 10.0.0.10
I would have thought that 10.0.0.10 isn't a local address since it is configured on the external interface FastEthernet 4. Or does the router mistakenly think that the interface is local? Besides, we do have a crypto map associated with FastEthernet 4 - it is in fact the only interface that has an associated crypto map. We're very confused - please help.
/Bjorn
03-21-2007 07:32 AM
Bjorn,
Can you please add this statement to the router, try it out again and send me the debugs.
crypto map SDM_CMAP_1 isakmp authorization list sdm_vpn_group_ml_1
Thanks
Gilbert
03-23-2007 05:19 AM
I'm afraid that didn't help either. We have an idea that the root of the problem is that the client receives a new IP address through mode config, but then it doesn't use this address in the phase 2 proposal so the gateway can't match the proposal to its acl's.
However, we've put mode config on hold and are looking at static client IP configuration instead so we won't have time to investigate further at the moment. Thank you for your suggestions though.
/Bjorn
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide