Solved: Re: IKEv2 with NAT-T and VRF

Jonathan Ridgway · ‎02-27-2014

Hi,

I'm struggling to get this to work and the IOS debug commands show nothing.

Spoke1

======

crypto ikev2 keyring LAN-to-LAN

peer HUB

identity address IP_1_PUBLIC

pre-shared-key local TEST

pre-shared-key remote TSET

!

crypto ikev2 profile IPSEC_IKEv2

match identity remote address IP_1_PUBLIC 255.255.255.255

identity local fqdn spoke1.domain.com

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

!

crypto ipsec transform-set ESP-TUNNEL esp-aes esp-sha-hmac

mode tunnel

!

crypto ipsec profile IPSEC

set transform-set ESP-TUNNEL

set ikev2-profile IPSEC_IKEv2

!

interface Tunnel2

description VTI2 | CUSTOMER2

vrf forwarding CUSTOMER2

ip unnumbered Loopback2

tunnel source Dialer1

tunnel mode ipsec ipv4

tunnel destination IP_1_PUBLIC

tunnel path-mtu-discovery

tunnel protection ipsec profile IPSEC

!

interface Loopback2

vrf forwarding CUSTOMER2

ip address IP_2_PRIVATE 255.255.255.255

!

interface Dialer1

ip address negociated

!

HUB

====

crypto ikev2 keyring LAN-to-LAN

peer spoke1.domain.com

identity fqdn spoke1.domain.com

pre-shared-key local TSET

pre-shared-key remote TEST

!

crypto ikev2 profile IPSEC_IKEv2

match identity remote fqdn spoke1.domain.com

identity local address IP_1_PUBLIC

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

virtual-template 2

!

crypto ipsec transform-set ESP-TUNNEL esp-aes esp-sha-hmac

mode tunnel

!

crypto ipsec profile IPSEC

set transform-set ESP-TUNNEL

set ikev2-profile IPSEC_IKEv2

!

interface Virtual-Template2 type tunnel

description VTI2 | CUSTOMER2

vrf forwarding CUSTOMER2

ip unnumbered Loopback2

tunnel source Loopback254

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile IPSEC

!

interface Loopback2

vrf forwarding CUSTOMER2

ip address IP_2_PRIVATE 255.255.255.255

!

interface Loopback254

ip address IP_1_PUBLIC 255.255.255.255

!

-----

The spoke can ping anything on the internet including the hub public facing address IP_1_PUBLIC but the tunnel does not come up. Each end is running RIPv2 under the "CUSTOMER2" context with "network 10.0.0.0" and no auto-summary. Static routes don't seem to kick it into life either. Any help would be much appreciated, thanks.

Marcin Latosiewicz · ‎02-27-2014

Cool! ;]

Remember that similar logic applies to spoke to spoke communication. i.e. what IP address/identity should I put as peer identity in the keyring? :-)

View solution in original post

Marcin Latosiewicz · ‎02-27-2014

I assume that the misspeling in pre-shared-keys is expected? TSET and TEST, I used this one during a training once

Scratch that, I see what you did there ;]

Debug this one. IKEv2 debugs to start with, both sides.

Other notes:

- Crypto logging session

- MTU and MSS missing from configuration.

Jonathan Ridgway · ‎02-27-2014

thanks for the response.

For some unexplainable reason when I switch on the following debugs:

Spoke1#debug crypto ikev2 client flexvpn

FlexVPN debugging is on

Spoke1#debug crypto ikev2 error

IKEv2 error debugging is on

Spoke1#debug crypto ikev2 packet

IKEv2 packet debugging is on

Nothing seems to show on the console

Spoke1#ping 8.8.8.8

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 580/645/700 ms

Spoke1#ping IP_1_PUBLIC

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to IP_1_PUBLIC, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 580/645/700 ms

*The high latency is because Dialer1 is currently on GPRS because 3G coverage where i'm testing is poor.

I have this in the Spoke1 config:

ip route vrf CUSTOMER2 10.47.0.0 255.255.0.0 Tunnel2

So I'd have thought pinging something like 10.47.255.252 would bring Tunnel2 up or show some debug messsages. Unfortunately all I get is this:

Spoke1#ping vrf CUSTOMER2 10.47.255.252

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.47.255.252, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Spoke1#sh ip route vrf CUSTOMER2:

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C 10.47.1.0/24 is directly connected, Vlan2

L 10.47.1.1/32 is directly connected, Vlan2

C 10.47.255.1/32 is directly connected, Loopback2

:/

How do I enable crypto logging session ?

And i'll try an MTU of 1452 just encase path-discovery isn't working?

My understanding is that a virtual-access interface should appear for each spoke that connects, but that doesn't seem to be happening.

Marcin Latosiewicz · ‎02-27-2014

Well you chose VTI... VTI will start negotiation as soon as the source interface is up and destination is reachable.

To enable crypto logging session

conf t

crypto logging session

Try just debug crypto ikev2 ... keep it basic. Make sure term mon is on.

If in doubt shut/no shut the tunnel interface on spoke side.

M.

Jonathan Ridgway · ‎02-27-2014

Thanks, I seemed to have "logging console critical" at the top of my config. I've removed that now so i'm seing all console messages again and I get a clear message in english now:

000180: *Feb 27 14:30:54.783: IKEv2:% Getting preshared key from profile keyring LAN-to-LAN

000181: *Feb 27 14:30:54.783: IKEv2:% key not found.

000182: *Feb 27 14:30:54.783: IKEv2:Failed to initiate sa

000180: *Feb 27 14:30:54.783: IKEv2:% Getting preshared key from profile keyring LAN-to-LAN

000181: *Feb 27 14:30:54.783: IKEv2:% key not found.

000182: *Feb 27 14:30:54.783: IKEv2:Failed to initiate sa

However, I can see a pre-shared key for the peer in my config so I'm not sure why it's saying that.

Jonathan Ridgway · ‎02-27-2014

It's now working !!!!!!!!!!!!!!!!!!

Before

---------

peer HUB

identity address IP_1_PUBLIC

pre-shared-key TEST

After

---------

peer HUB

address IP_1_PUBLIC

identity address IP_1_PUBLIC

pre-shared-key TEST

Isn't it amazing how easy it is to solve problems when you can see the debug messages? Just because I was using the hub's loopback as identiy wasn't enough to get the spoke to chose which key to use, because I had to also specify the address which matches "tunnel destination" (which in this case happens to be the same address).

Marcin Latosiewicz · ‎02-27-2014

Cool! ;]

Remember that similar logic applies to spoke to spoke communication. i.e. what IP address/identity should I put as peer identity in the keyring? :-)

IKEv2 with NAT-T and VRF (FlexVPN)