Re: GRE with IPSec

Argo · ‎12-12-2017

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

GioGonza · ‎12-12-2017

Hello @Argo,

Can you share the configuration in order to check further?

Gio

Argo · ‎12-12-2017

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

Argo · ‎12-12-2017

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.

Argo · ‎12-12-2017

*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

Argo · ‎12-12-2017

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....

GioGonza · ‎12-12-2017

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

Argo · ‎12-13-2017

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

Argo · ‎12-13-2017

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

Argo · ‎12-13-2017

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

Argo · ‎12-13-2017

seeing following error in the logs on the hub

crypto_engine_select_crypto_engine: can't handle any more

Argo · ‎12-13-2017

on a hub :

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

Argo · ‎12-13-2017

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

Argo · ‎12-13-2017

suspecting vrf issue on the spoke side