cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1429
Views
0
Helpful
13
Replies

GRE with IPSec

Argo
Level 1
Level 1

Hi,

In the log am getting:

ISAKMP:(0): No Cert or pre-shared address key.

 

I know there is a key configured for sure, wonder why it doesn't pick it up ?

Identical configuration on both tunnel sides. GRE tunnel is coming up. Once you start applying

ipsec it goes down and am seeing that problem about key or a cert. Am not sure whether I should  b e looking into the certs cause the key is used.  But just for the sake of mind cert does show on one side but not the other when you issue the command - sh crypto ca certificates. ISR4351/K9 with C3900-SPE150/K9

13 Replies 13

GioGonza
Level 4
Level 4

Hello @Argo

 

Can you share the configuration in order to check further?

 

Gio

Hi,

 

Thanks for looking into.

I have tried both scenarios – ikev1 and ikev2 with no success.

Currently have stopped with ikev1.  So it is a hub and  spoke case.

Spoke has another ikev2 tunnel running fine, which needs to be migrated

to a new hub.  And on new hub all the tunnels done with ikev1 so better

to stick with same version.  I have removed keepalive for now, but gre tunnel

works fine with it.

 

Configuration applied is following:

 

crypto keyring XXX-Keys

  pre-shared-key address 194.x.x.x key fewfwfwwadwfw

 

crypto isakmp policy 1

 encr aes 256

 authentication pre-share

 group 5

 

crypto isakmp policy 2

 encr aes

 authentication pre-share

 

crypto isakmp profile ISAKMP-Profile

   keyring XXX-Keys

   match identity address 194.x.x.x 255.255.255.255

 

crypto ipsec transform-set transform_set-AES256VPN esp-aes esp-sha-hmac

 mode transport  (have tried mode tunnel  as well , not sure about difference and which needs to be )

 

crypto ipsec profile aaa-test

 set transform-set transform_set-AES256VPN

 set isakmp-profile ISAKMP-Profile

 

interface Tunnel25

 description ………

 ip address 10.128.252.5 255.255.255.252

 ip mtu 1400

 ip tcp adjust-mss 1360

 tunnel source GigabitEthernet0/1

 tunnel mode ipsec ipv4

 tunnel destination 196.x.x.x

 tunnel protection ipsec profile aaa-test

 

 

I have tried defining secret key the other way as well and using different ipsec profile

crypto isakmp key kja;ekwmd.snd.snmd;s address 194.x.x.x

 

 

 

ISAKMP:(0):Can not start Aggressive mode, trying Main mode.

ISAKMP:(0): No Cert or pre-shared address key.

 ISAKMP:(0): construct_initial_message: Can not start Main mode

 

ISAKMP: Error while processing SA request: Failed to initialize SA

ISAKMP: Error while processing KMI message 0, error 2.

*Dec 12 18:12:10: ISAKMP: (0):SA request profile is ISAKMP-Profile

*Dec 12 18:12:10: ISAKMP: (0):Created a peer struct for 196.x.x.x, peer port 500

*Dec 12 18:12:10: ISAKMP: (0):New peer created peer = 0x17D3D79C peer_handle = 0x800921A4

*Dec 12 18:12:10: ISAKMP: (0):Locking peer struct 0x17D3D79C, refcount 1 for isakmp_initiator

*Dec 12 18:12:10: ISAKMP: (0):local port 500, remote port 500

*Dec 12 18:12:10: ISAKMP: (0):set new node 0 to QM_IDLE

*Dec 12 18:12:10: ISAKMP: (0):Find a dup sa in the avl tree during calling isadb_insert sa = 39768D4

*Dec 12 18:12:10: ISAKMP: (0):Can not start Aggressive mode, trying Main mode.

*Dec 12 18:12:10: ISAKMP: (0):Found ADDRESS key in keyring XXX-keys

*Dec 12 18:12:10: ISAKMP: (0):constructed NAT-T vendor-rfc3947 ID

*Dec 12 18:12:10: ISAKMP: (0):constructed NAT-T vendor-07 ID

*Dec 12 18:12:10: ISAKMP: (0):constructed NAT-T vendor-03 ID

*Dec 12 18:12:10: ISAKMP: (0):constructed NAT-T vendor-02 ID

*Dec 12 18:12:10: ISAKMP: (0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

*Dec 12 18:12:10: ISAKMP: (0):Old State = IKE_READY  New State = IKE_I_MM1

First debug was from a spoke and second from a hub.

As it looks the hub does confirm it found the key....which is opposite to spoke.

Spoke has another public interface but just for ssh and routing is correct anyway....

Hello @Argo

 

I was checking the configuration and based on the logs you are trying to a peer IP as 196.x.x.x but the configuration for the keyring starts with another IP as 194.x.x.x

 

crypto keyring XXX-Keys

  pre-shared-key address 194.x.x.x key fewfwfwwadwfw

 

crypto isakmp profile ISAKMP-Profile

   keyring XXX-Keys

   match identity address 194.x.x.x 255.255.255.255

 

interface Tunnel25

 description ………

 ip address 10.128.252.5 255.255.255.252

 ip mtu 1400

 ip tcp adjust-mss 1360

 tunnel source GigabitEthernet0/1

 tunnel mode ipsec ipv4

 tunnel destination 196.x.x.x >> It´s the only thing that is a mismatch on the configuration

 tunnel protection ipsec profile aaa-test

 

Verify that and let me know if that is the concern. 

 

BTW, it should be mode tunnel

 

crypto ipsec transform-set transform_set-AES256VPN esp-aes esp-sha-hmac

 mode transport

 

HTH

Gio

Hi,

 

It was just a typo while copy/pasting from different end devices.  IP addresses are correct.

Have swapped the mode to tunnel.  Spoke also is running vrf to make things more complicate )

So wonder if vrf needs to be mentioned anywhere. The other tunnel is built on ikev2 but trying

to replicate with vrf it did't work either.

Shall I apply under:

crypto isakmp profile ......

vrf internet

 

Anything else potentially

someone suggested adding vrf under keyring and isakmp profile.

So now I have status Active of Phase 1 !

 

crypto keyring XXX-Keys vrf internet
  pre-shared-key address 194.x.x.x key .............

 

crypto isakmp profile ISAKMP-Profile
   vrf internet
   keyring XXX-Keys
   match identity address 194.x.x.x 255.255.255.255

 

 

 

......#sh crypto isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
194.29.71.16    196.219.5.151   MM_NO_STATE          0 ACTIVE ISAKMP-Profile

 

 

 

I wonder if SA established as the state says MM_NO_STATE, though statis is Active. Should state be QM_IDLE ?

seeing following error in the logs on the hub

crypto_engine_select_crypto_engine: can't handle any more

on a hub :

ISAKMP-ERROR: (0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 196.x.x.x)

crypto ipsec transform-set  needs to be in transport mode other-ways original IP header will get encrypted which is not welcomed. That's what papers say about ipsec over gre.

 

crypto ipsec transform-set transform_set-AES256VPN esp-aes esp-sha-hmac
 mode transport

suspecting vrf issue on the spoke side