06-15-2006 12:11 AM - edited 02-21-2020 02:28 PM
Hi all,
this is my first post here,and i hope to not violate any forum rules.I have an issue with ipsec (actualy this is my first "date" with Cisco crypto tools). Here is the situation: i got 2 cisco routers (1751) with c1700-advsecurityk9-mz.123-19 IOS. I'm tryin to secure the connection between two devices (in lab circumstances) with ipsec in tunnel mode. Everything works fine , until my interest to start the crypto over GRE tunnel. When i raise the tunnel , i put the `crypto map <mapname>` to the tunnel device ,and my troubles begin. The traffic between two endpoits (matched with access list for the 'interesting traffic') has gone. After little investigation i found this:
(i will paste a part of configuration from router `A`)
crypto isakmp policy 5
encr aes 256
authentication pre-share
lifetime 360
crypto isakmp key cIpHeR address 20.20.20.2
!
crypto ipsec transform-set london esp-aes 256 esp-md5-hmac
crypto ipsec df-bit clear
!
crypto map London 5 ipsec-isakmp
set peer 20.20.20.2
set transform-set london
match address crypt
!
interface Tunnel1
bandwidth 100
ip address 20.20.20.1 255.255.255.252
ip mtu 1400
ip route-cache flow
load-interval 30
cdp enable
tunnel source 10.10.10.4
tunnel destination 10.10.10.3
tunnel key 1
tunnel path-mtu-discovery
crypto map London
!
Paris#show crypto ipsec sa
interface: Tunnel1
Crypto map tag: London, local addr. 10.10.10.4
current_peer: 20.20.20.2:500
[cut]
local crypto endpt.: 10.10.10.4, remote crypto endpt.: 20.20.20.2
path mtu 1400, ip mtu 1400, ip mtu idb Tunnel1
current outbound spi: 0
[cut]
I think that the issue is comming because of 'Local addr. 10.10.10.4' that sould be '20.20.20.1'
and the 'local crypto endpt.: 10.10.10.4' should be '20.20.20.1'. So i blame this for a reason of the case
because the tunnel needs to be done between 20.20.20.1 and 20.20.20.2 NOT between 10.10.10.4 <=> 20.20.20.2.
Does anyone have have an idea why this is happen?
At the other site , the sittuation is the same:
crypto isakmp policy 5
encr aes 256
authentication pre-share
lifetime 360
crypto isakmp key cIpHeR address 20.20.20.1
!
!
crypto ipsec transform-set paris esp-aes 256 esp-md5-hmac
crypto ipsec df-bit clear
!
crypto map Paris 5 ipsec-isakmp
set peer 20.20.20.1
set transform-set paris
match address crypt
!
interface Tunnel1
bandwidth 100
ip address 20.20.20.2 255.255.255.252
ip mtu 1400
no ip route-cache cef
load-interval 30
cdp enable
tunnel source 10.10.10.3
tunnel destination 10.10.10.4
tunnel key 1
crypto map Paris
!
London#show crypto ipsec sa
interface: Tunnel1
Crypto map tag: Paris, local addr. 10.10.10.3
current_peer: 20.20.20.1:500
[cut]
local crypto endpt.: 10.10.10.3, remote crypto endpt.: 20.20.20.1
path mtu 1400, ip mtu 1400, ip mtu idb Tunnel1
current outbound spi: 0
[cut]
Again the same issue , 'local addr. 10.10.10.3' and 'local crypto endpt.: 10.10.10.3'.
London#debug crypto ipsec
Sep 20 16:23:30.075: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 10.10.10.3, remote= 20.20.20.1,
Sep 20 16:24:00.071: IPSEC(key_engine): request timer fired: count = 1,
(identity) local= 10.10.10.3, remote= 20.20.20.1,
local_proxy= 192.168.252.0/255.255.255.252/0/0 (type=4),
remote_proxy= 192.168.253.0/255.255.255.0/0/0 (type=4)
London#show crypto isakmp sa
dst src state conn-id slot
20.20.20.1 10.10.10.3 MM_KEY_EXCH 2 0
The IKE/ISAKMP is tryin to make the connection with WRONG source addres , and the Phase2 of IPSec could NOT been completed.
Any suggestions are welcome!
Thanks in advance for your effort to answare this question.
Best Regards,
Danail Petrov
P.s. Please excuse my english
Solved! Go to Solution.
06-16-2006 08:03 AM
Danail
I am glad that you found a solution for your problem. Tunnel protection is a good feature and I am glad that you found it.
Thank you for posting back to the forum and indicating that you have a solution and what the solution is. It makes the forum more useful when we can read about a problem and then see what fixed the problem.
I encourage you to continue your participation in the forum.
HTH
Rick
06-15-2006 10:39 AM
Danail
I believe that there may be a couple of issues. First and most important is the question of peer address. By default the router believe that the local peer address is the address of the outbound interface unless you configure it differently. So I suggest that you add this to your crypto map:
crypto map London local-address tunnel1
and do the same on the other router changing London to Paris. This will cause the router to use the peering address as the tunnel address which is what you are asking.
Second may be an issue of the crypto map access list to identify traffic to be protected by IPSec. You reference a crypto map named crypt but do not show its contents. If you first tested IPSec on the routers without GRE then crypt probably specifies the subnet where users are as source and destination. When you introduce GRE it changes what the access list needs to identify. Now the access list should specify the tunnel source and tunnel destination.
Third may be the location of the crypto map. In earlier versions of IOS the crypto map needs to be on both the tunnel interface and the physical interface. In recent versions of code (I know I am doing it in 12.3T and do not remember exactly when it was introduced - so do not know if it applies to your version of IOS) the crypto map should be on the physical interface and not on the tunnel interface.
Try these suggestions and let us know what happens.
HTH
Rick
06-15-2006 11:19 PM
Hello Rick,
because of limit that i have to post message here, i should remove most of information.
I try with `crypto map London local-address tunnel1` (before i post here) , but there is no results. The src address still was 10.10.10.x.
The 'interesting traffic' matched by `crypt` access list is :
10 permit ip 192.168.252.0 0.0.0.255 192.168.253.0 0.0.0.255
20 permit ip 192.168.253.0 0.0.0.255 192.168.252.0 0.0.0.255 (245 matches)
I try to put the `crypto map` to physical interfaces that forms Tu1 interfaces , but nothing. When i remove the crypto map from the tu1 interface , and applyin her to the physical interfaces only , the connection between 192.168.252.2 -> 192.168.253.1 is appear BUT the traffic is not encrypted . After little research , i found a workaround for this issue -> using profiles , and applying the profile to the Tunnel interface with ` tunnel protection ipsec profile
Here is the configuration that solve my problem:
crypto isakmp policy 10
encr 3des
authentication pre-share
group 5
!
crypto isakmp policy 20
hash md5
authentication pre-share
group 2
crypto isakmp key xxx address 0.0.x.x.0.0.0 no-xauth
!
!
crypto ipsec transform-set paris esp-3des esp-sha-hmac
mode transport
!
crypto ipsec profile Paris
set security-association lifetime seconds 120
set transform-set paris
!
interface Tunnel1
bandwidth 100
ip address 20.20.x.x.255.255.252
ip mtu 1400
load-interval 30
cdp enable
tunnel source 10.10.10.3
tunnel destination 10.10.10.4
tunnel key 1
tunnel protection ipsec profile Paris
and the same config (with little diff at the other side)
Thank you for your effort.
Best Regards,
Danail Petrov
06-16-2006 08:03 AM
Danail
I am glad that you found a solution for your problem. Tunnel protection is a good feature and I am glad that you found it.
Thank you for posting back to the forum and indicating that you have a solution and what the solution is. It makes the forum more useful when we can read about a problem and then see what fixed the problem.
I encourage you to continue your participation in the forum.
HTH
Rick
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