cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2816
Views
0
Helpful
3
Replies

IPSec sa local crypto endpt

danail-petrov
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

HTH

Rick

View solution in original post

3 Replies 3

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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

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

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: