Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Make tunnel interfaces match up

SPOKE:

                  

interface Tunnel1

description CUSTOMER1

vrf forwarding CUSTOMER1

ip unnumbered Loopback1

tunnel source Dialer1

tunnel mode ipsec ipv4

tunnel destination dynamic

tunnel path-mtu-discovery

tunnel protection ipsec profile IPSEC

interface Tunnel2

description CUSTOMER2

vrf forwarding CUSTOMER2

ip unnumbered Loopback2

tunnel source Dialer1

tunnel mode ipsec ipv4

tunnel destination dynamic

tunnel path-mtu-discovery

tunnel protection ipsec profile IPSEC

HUB:

interface Virtual-Template1 type tunnel

description CUSTOMER1

vrf forwarding CUSTOMER1

ip unnumbered Loopback1

tunnel source Loopback254

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile IPSEC

!

interface Virtual-Template2 type tunnel

description CUSTOMER2

vrf forwarding CUSTOMER2

ip unnumbered Loopback2

tunnel source Loopback254

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile IPSEC

!

---

Both these tunnels connect but when I look at the routing table of CUSTOMER1 it has CUSTOMER2 routes in it and vice versa. Other than using a different public loopback address at the hub for each template, is there a better way to ensure Tunnel1 on the spoke only connects to Virtual-Template1 at the hub and Tunnel2 on the spoke only connects to Virtual-Template 2 at the hub etc...?

Any help much appreciated.

Jonathan

17 REPLIES
Cisco Employee

Make tunnel interfaces match up

Jonathan,

If you want both of the tunnels to be up at the same time... from the top of my head.

- Use GRE instead of VTI, with different tunnel key.

- If you want to match up VRF on both/multiple sides/sites, use one tunnel and run MPLS on top of GRE instead of multiple tunnels.

M.

New Member

Make tunnel interfaces match up

ahhhh, didn't know about "tunnel key". That's done the trick as a "selector".

However it does look like I might be going about this in the wrong way and perhaps i'll try MPLSoGRE instead.

Cisco Employee

Make tunnel interfaces match up

If going for MPLS over FlexVPN (if this is flex) make sure/double check whether you need spoke to spoke features.

I believe that was something introduced pretty recently. Spoke->hub should work fine.

New Member

Make tunnel interfaces match up

Hmmmm, since changing from "tunnel mode ipsec ip" to "tunnel mode gre ip" so I can use the "tunnel key x" feature as a selector, the tunnel won't stay up and the dynamic routing protocol isn't bringing anything through anymore. Are there other considerations when using GRE ?

Cisco Employee

Make tunnel interfaces match up

That depends, as usual :-)

Is that Flex?

What is the RP?

What is the platform?

Are the spoke(s) behind NAT?

There are mutliple examples out there for starters I would say you do not need tunnel source on your VTs (if this if flex)

Looks like your problem COULD be related to one way traffic - typically due to some misconfig.

M.

New Member

Re: Make tunnel interfaces match up

Yes to flex

RIPv2 is the routing protocol, with MD5 authentication.

IOS 15.0 on each end

Yeah the spokes on on O2-UK mobile broadband: a private IP address that get's PAT'd.

I'm using the flexvpn client on the spoke to get hub redundancy:

crypto ikev2 client flexvpn Tunne1

  peer 1 *hub 1 ip*

  peer 2 *hub 2 ip*

  client connect Tunnel1

!

crypto ikev2 client flexvpn Tunnel2

  peer 1 *hub 1 ip*

  peer 2 *hub 2 ip*

  client connect Tunnel2

!

Thats why I have "tunnel destination dynamic" on my VTI's and "dpd 30 2 on-demand" under the IKEv2 profile. Everything works fine when I use "tunnel mode ipsec ipv4". Should I try and remove tunnel source from the hub end or the remote end ?

Cisco Employee

Re: Make tunnel interfaces match up

Hmmmm and what's the headend platform ... is there a chance that spokes are visible under same public IP address?

And seriously 15.0? 15.2(4)M is the minimum I would try this on 15.3.3M would be a decent starting point.

New Member

Re: Make tunnel interfaces match up

Oops thats the bootstrap version,

Hubs:

Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.2(4)M4, RELEASE SOFTWARE (fc2)

Spokes:

Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M4, RELEASE SOFTWARE (fc2)

That could be the case but I'd hope NAT-T would take case of that by allowing the UDP port to be changed in transit by PAT without effecting the integrity of IPSec. Also i'm just doing this on the one spoke for now.

I have a feeling i've missed something really basic here but it's not jumping out at me. I'm trying to think of the things that makes IPSec-GRE/IP different to straight forward IPSec/IP. One thing I'm fairly sure on is that this is a routing problem. I think the fact the tunnel is coming up and down is a consequence of the GRE keep alive and FlexVPN moving on to try another hub.

Cisco Employee

Re: Make tunnel interfaces match up

I was asking about NAT and headend because of this:

https://tools.cisco.com/bugsearch/bug/CSCue00443/?reffering_site=dumpcr

But it only affecting ASR1k.

Post the cofigs, obfuscate the IPs if needed, I'll have a look when possible.

Tunnel source is indeed not needed, you can start there and enable crypto logging session :]

New Member

Re: Make tunnel interfaces match up

Hi Marcin,

Thanks for having the time to look at this for me. Here are the full configs (well the bits that I believe are relevant)

Hub:

====

key chain RIP

key 1

  key-string 0 ***

!

!

crypto ikev2 proposal default

encryption ***

integrity ***

group ***

!

!

crypto ikev2 keyring LAN-to-LAN

peer LAN-to-LAN

  address 0.0.0.0 0.0.0.0

  pre-shared-key ***

!

!

!

crypto ikev2 profile CUSTOMER1

match fvrf any

match identity remote fqdn spoke1.com_CUSTOMER1

match identity remote fqdn spoke2.com_CUSTOMER1

identity local fqdn hub1.com_CUSTOMER1

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

virtual-template 1

!

crypto ikev2 profile CUSTOMER2

match fvrf any

match identity remote fqdn spoke1.com_CUSTOMER2

match identity remote fqdn spoke2.com_CUSTOMER2

identity local fqdn hub1.com_CUSTOMER2

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

virtual-template 2

!

crypto ikev2 profile CUSTOMER3

match fvrf any

match identity remote fqdn spoke1.com_CUSTOMER3

match identity remote fqdn spoke2.com_CUSTOMER3

identity local fqdn hub1.com_CUSTOMER3

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

virtual-template 3

!

!

crypto ipsec transform-set ESP-TUNNEL esp-*** esp-***

mode tunnel

!

!

crypto ipsec profile CUSTOMER1

set transform-set ESP-TUNNEL

set ikev2-profile CUSTOMER1

!

crypto ipsec profile CUSTOMER2

set transform-set ESP-TUNNEL

set ikev2-profile CUSTOMER2

!

crypto ipsec profile CUSTOMER3

set transform-set ESP-TUNNEL

set ikev2-profile CUSTOMER3

!

!

interface Virtual-Template1 type tunnel

vrf forwarding CUSTOMER1

ip unnumbered Loopback1

ip rip authentication mode md5

ip rip authentication key-chain RIP

tunnel source *PUBLIC ADDRESS*

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile CUSTOMER1

!

interface Virtual-Template2 type tunnel

vrf forwarding CUSTOMER2

ip unnumbered Loopback2

ip rip authentication mode md5

ip rip authentication key-chain RIP

tunnel source *PUBLIC ADDRESS*

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile CUSTOMER2

!

interface Virtual-Template3 type tunnel

vrf forwarding CUSTOMER3

ip unnumbered Loopback3

ip rip authentication mode md5

ip rip authentication key-chain RIP

tunnel source *PUBLIC ADDRESS*

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile CUSTOMER3

!

interface Loopback1

vrf forwarding CUSTOMER1

192.168.1.1 255.255.255.255

!

interface Loopback2

vrf forwarding CUSTOMER2

192.168.2.1 255.255.255.255

!

interface Loopback3

vrf forwarding CUSTOMER3

192.168.3.1 255.255.255.255

!

router rip

!

address-family ipv4 vrf CUSTOMER1

  network 192.168.1.0

  version 2

  no auto-summary

exit-address-family

!

address-family ipv4 vrf CUSTOMER2

  network 192.168.2.0

  version 2

  no auto-summary

exit-address-family

!

address-family ipv4 vrf CUSTOMER3

  network 192.168.3.0

  version 2

  no auto-summary

exit-address-family

Spoke1:

=======

key chain RIP

key 1

  key-string 0 ***

!

!

crypto ikev2 proposal default

encryption ***

integrity ***

group ***

!

!

crypto ikev2 keyring LAN-to-LAN

peer LAN-to-LAN

  address 0.0.0.0 0.0.0.0

  pre-shared-key ***

!

!

!

crypto ikev2 profile CUSTOMER1

match fvrf any

match identity remote fqdn hub1.com_CUSTOMER1

match identity remote fqdn hub2.com_CUSTOMER1

identity local fqdn spoke1.com_CUSTOMER1

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

dpd 10 2 on-demand

!

crypto ikev2 profile CUSTOMER2

match fvrf any

match identity remote fqdn hub1.com_CUSTOMER2

match identity remote fqdn hub2.com_CUSTOMER2

identity local fqdn spoke1.com_CUSTOMER2

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

dpd 10 2 on-demand

!

crypto ikev2 profile CUSTOMER3

match fvrf any

match identity remote fqdn hub1.com_CUSTOMER3

match identity remote fqdn hub2.com_CUSTOMER3

identity local fqdn spoke1.com_CUSTOMER3

authentication remote pre-share

authentication local pre-share

keyring local LAN-to-LAN

dpd 10 2 on-demand

!

!

crypto ikev2 client flexvpn Tunnel1

  peer 1 hub1.com

  peer 2 hub2.com

  client connect Tunnel1

!

crypto ikev2 client flexvpn Tunnel2

  peer 1 hub1.com

  peer 2 hub2.com

  client connect Tunnel2

!

crypto ikev2 client flexvpn Tunnel3

  peer 1 hub1.com

  peer 2 hub2.com

  client connect Tunnel3

!

!

crypto ipsec transform-set ESP-TUNNEL esp-*** esp-***

mode tunnel

!

!

crypto ipsec profile CUSTOMER1

set transform-set ESP-TUNNEL

set ikev2-profile CUSTOMER1

!

crypto ipsec profile CUSTOMER2

set transform-set ESP-TUNNEL

set ikev2-profile CUSTOMER2

!

crypto ipsec profile CUSTOMER3

set transform-set ESP-TUNNEL

set ikev2-profile CUSTOMER3

!

!

interface Tunnel1

vrf forwarding CUSTOMER1

ip unnumbered Loopback1

ip rip authentication mode md5

ip rip authentication key-chain RIP

tunnel source Dialer1

tunnel mode ipsec ipv4

tunnel destination dynamic

tunnel path-mtu-discovery

tunnel protection ipsec profile CUSTOMER1

!

interface Tunnel2

vrf forwarding CUSTOMER2

ip unnumbered Loopback2

ip rip authentication mode md5

ip rip authentication key-chain RIP

tunnel source Dialer1

tunnel mode ipsec ipv4

tunnel destination dynamic

tunnel path-mtu-discovery

tunnel protection ipsec profile CUSTOMER2

!

interface Tunnel3

vrf forwarding CUSTOMER3

ip unnumbered Loopback3

ip rip authentication mode md5

ip rip authentication key-chain RIP

tunnel source Dialer1

tunnel mode ipsec ipv4

tunnel destination dynamic

tunnel path-mtu-discovery

tunnel protection ipsec profile CUSTOMER3

!

interface Loopback1

vrf forwarding CUSTOMER1

192.168.1.2 255.255.255.255

!

interface Loopback2

vrf forwarding CUSTOMER2

192.168.2.2 255.255.255.255

!

interface Loopback3

vrf forwarding CUSTOMER3

192.168.3.2 255.255.255.255

!

router rip

!

address-family ipv4 vrf CUSTOMER1

  network 192.168.1.0

  version 2

  no auto-summary

exit-address-family

!

address-family ipv4 vrf CUSTOMER2

  network 192.168.2.0

  version 2

  no auto-summary

exit-address-family

!

address-family ipv4 vrf CUSTOMER3

  network 192.168.3.0

  version 2

  no auto-summary

exit-address-family

!

Cisco Employee

Re: Make tunnel interfaces match up

I assume that the typos in VT numbers are expected? (profiles indicate number 2, 30 and 3, while configured ones are 1,2,3).

We already discussed, problem with IPsec IPv4 is demultiplexing the flows between same IP addresses.

You canrtermiante IPsec sessions on different interfaces on same hub routers (loopback for example)... which could potentially work.

You had some problems with GRE over IPsec, were they persisting with only one tunnel active at a time between spoke and hub?

M.

New Member

Re: Make tunnel interfaces match up

Hi there,

Oops they got left behind when obscuring the real ip's and tunnel numbers; I've corrected it now.

Yeah I see what you mean about demultiplexing, I think that's what I'm seing. I tried GRE with "tunnel key" then 1,2,3 so the sVTI matches up with the dVTI at the hub end, but for some reason this wouldn't work at all even with just the one tunnel active (tunnel 1). I guess this is a routing issue but I couldn't see it.

I was just wondering if that would work, if I use a different public IP at the hub end for each virtual-template I guess that should work?

Cisco Employee

Re: Make tunnel interfaces match up

Yes, different IP addresses for termination on hub side would work.

One caveat. You need to make sure you select the correct IKEv2 profile ("tunnel source" command will not work AFAIR) during IKE negotiation. Should not be a big problem in your case.

What I would really like to see is a case open with one of the VPN teams. The GRE approach should work unless I forgot everything in last 10 months ;-)

New Member

Re: Make tunnel interfaces match up

Thanks i'll give it a try and see if works. It would be good to figure out why GRE wasn't working as this will save on public IPv4 addresses.

New Member

Re: Make tunnel interfaces match up

I've simplified things a bit:

HUB:

====

no crypto ikev2 client flexvpn Tunnel1

no crypto ikev2 client flexvpn Tunnel2

no crypto ikev2 client flexvpn Tunnel3

no interface tunnel1

no interface tunnel2

interface tunnel2

  tunnel destination HUB1

REMOTE:

========

interface Virtual-Template1 type tunnel

  no tunnel source

  shutdown

interface Virtual-Template2 type tunnel

  no tunnel source

  shutdown

So there is only tunnel3 at the remote end and only virtual-template 3 listening on the loopback address on the HUB end. In addition to this, the remote is statically configured with the destination of the hub (no flexvpn client hub redundancy). And this still doens't work. There is something in the configuration above with Tunnels 2 and 3 which the routers at both ends do not like and it's not jumping out at me because other than changing the VRF name on the end of the identities, it looks the same.

-------

Here is the debug output from begining to end (with source and destination IP's removed):

004037: .Mar  5 15:32:00.633: IKEv2:% Getting preshared key from profile keyring LAN-to-LAN
004038: .Mar  5 15:32:00.633: IKEv2:% Matched peer block 'LAN-to-LAN'
004039: .Mar  5 15:32:00.633: IKEv2:Searching Policy with fvrf 0, local address SPOKE1
004040: .Mar  5 15:32:00.633: IKEv2:Using the Default Policy for Proposal
004041: .Mar  5 15:32:00.633: IKEv2:Found Policy 'default'
004042: .Mar  5 15:32:00.633: IKEv2:(SA ID = 1):[IKEv2 -> Crypto Engine] Computing DH public key, DH Group 19
004043
SPOKE1(config)#: .Mar  5 15:32:00.633: IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] DH key Computation PASSED
004044: .Mar  5 15:32:00.633: IKEv2:(SA ID = 1):Request queued for computation of DH key
004045: .Mar  5 15:32:00.633: IKEv2:IKEv2 initiator - no config data to send in IKE_SA_INIT exch
004046: .Mar  5 15:32:00.633: IKEv2:(SA ID = 1):Generating IKE_SA_INIT message
004047: .Mar  5 15:32:00.633: IKEv2:(SA ID = 1):IKE Proposal: 1, SPI size: 0 (initial negotiation),
Num. transforms: 7
   AES-CBC   SHA256   SHA1
SPOKE1(config)#  SHA256   SHA96   DH_GROUP_256_ECP/Group 19   DH_GROUP_2048_MODP/Group 14

004048: .Mar  5 15:32:00.633: IKEv2:(SA ID = 1):Sending Packet [To HUB1:500/From SPOKE1:500/VRF i0:f0]
Initiator SPI : EECCD9476A6301DE - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
Payload contents:
SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)

004049: .Mar  5 15:32:00.637: IKEv2:(SA ID = 1):Insert SA
SPOKE1(config)#
004050: .Mar  5 15:32:02.585: IKEv2:(SA ID = 1):Retransmitting packet

004051: .Mar  5 15:32:02.585: IKEv2:(SA ID = 1):Sending Packet [To HUB1:500/From SPOKE1:500/VRF i0:f0]
Initiator SPI : EECCD9476A6301DE - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
Payload contents:
SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)


004052: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):Received Packet [From HUB1
SPOKE1(config)#54:500/To SPOKE1:500/VRF i0:f0]
Initiator SPI : EECCD9476A6301DE - Responder SPI : E0D14C006A000813 Message id: 0
IKEv2 IKE_SA_INIT Exchange RESPONSE
Payload contents:
SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)

004053: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):Processing IKE_SA_INIT message
004054: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):Verify SA init message
004055: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):Processing IKE_SA_INIT message
004056: .
SPOKE1(config)#Mar  5 15:32:03.173: IKEv2:(SA ID = 1):Checking NAT discovery
004057: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):NAT INSIDE found
004058: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):NAT detected float to init port 4500, resp port 4500
004059: .Mar  5 15:32:03.173: IKEv2:(SA ID = 1):[IKEv2 -> Crypto Engine] Computing DH secret key, DH Group 19
004060: .Mar  5 15:32:03.197: IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] DH key Computation PASSED
004061: .Mar  5 15:32:03.197: IKEv2:(SA ID = 1):Request queued for co
SPOKE1(config)#mputation of DH secret
004062: .Mar  5 15:32:03.197: IKEv2:(SA ID = 1):[IKEv2 -> Crypto Engine] Calculate SKEYSEED and create rekeyed IKEv2 SA
004063: .Mar  5 15:32:03.197: IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] SKEYSEED calculation and creation of rekeyed IKEv2 SA PASSED
004064: .Mar  5 15:32:03.197: IKEv2:(SA ID = 1):Completed SA init exchange
004065: .Mar  5 15:32:03.197: IKEv2:Config data to send:
004066: .Mar  5 15:32:03.197: Config-type: Config-request
004067: .Mar  5 15:32:03.197: Attrib t
SPOKE1(config)#ype: ipv4-dns, length: 0
004068: .Mar  5 15:32:03.197: Attrib type: ipv4-dns, length: 0
004069: .Mar  5 15:32:03.197: Attrib type: ipv4-nbns, length: 0
004070: .Mar  5 15:32:03.197: Attrib type: ipv4-nbns, length: 0
004071: .Mar  5 15:32:03.197: Attrib type: ipv4-subnet, length: 0
004072: .Mar  5 15:32:03.197: Attrib type: app-version, length: 244, data: Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M5, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupp
SPOKE1(config)#ort
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Fri 13-Sep-13 14:59 by prod_rel_team
004073: .Mar  5 15:32:03.197: Attrib type: split-dns, length: 0
004074: .Mar  5 15:32:03.197: Attrib type: banner, length: 0
004075: .Mar  5 15:32:03.197: Attrib type: config-url, length: 0
004076: .Mar  5 15:32:03.197: Attrib type: backup-gateway, length: 0
004077: .Mar  5 15:32:03.201: Attrib type: def-domain, length: 0
004078: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Have config mode data to send
004
SPOKE1(config)#079: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Check for EAP exchange
004080: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Generate my authentication data
004081: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Use preshared key for id SPOKE1_CUSTOMER3, key len 6
004082: .Mar  5 15:32:03.201: IKEv2:[IKEv2 -> Crypto Engine] Generate IKEv2 authentication data
004083: .Mar  5 15:32:03.201: IKEv2:[Crypto Engine -> IKEv2] IKEv2 authentication data generation PASSED
004084: .Mar  5 15:32:03.201:
SPOKE1(config)#IKEv2:(SA ID = 1):Get my authentication method
004085: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):My authentication method is 'PSK'
004086: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Check for EAP exchange
004087: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Generating IKE_AUTH message
004088: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Constructing IDi payload: 'SPOKE1_CUSTOMER3' of type 'FQDN'
004089: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):ESP Proposal: 1, SPI size: 4 (IPSec negotiation)
SPOKE1(config)#,
Num. transforms: 3
   AES-CBC   SHA96   Don't use ESN
004090: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Building packet for encryption.
Payload contents:
VID IDi AUTH CFG SA TSi TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)

004091: .Mar  5 15:32:03.201: IKEv2:(SA ID = 1):Sending Packet [To HUB1:4500/From SPOKE1:4500/VRF i0:f0]
Initiator SPI : EECCD9476A6301DE - Responder SPI : E0D14C006A000813 Message id: 1
IKEv2 IKE_A
SPOKE1(config)#UTH Exchange REQUEST
Payload contents:
ENCR

004092: .Mar  5 15:32:03.617: IKEv2:(SA ID = 1):Packet is a retransmission
004093: .Mar  5 15:32:03.617: IKEv2:Packet is a retransmission

004094: .Mar  5 15:32:03.617: IKEv2:

004095: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Received Packet [From HUB1:4500/To SPOKE1:4500/VRF i0:f0]
Initiator SPI : EECCD9476A6301DE - Responder SPI : E0D14C006A000813 Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
Payload contents:
NOTIFY(AUTHEN
SPOKE1(config)#TICATION_FAILED)

004096: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Process auth response notify
004097: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):
004098: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Auth exchange failed
004099: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Auth exchange failed

004100: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Auth exchange failed
004101: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Abort exchange
004102: .Mar  5 15:32:04.337: IKEv2:(SA ID = 1):Deleting SA

Cisco Employee

Re: Make tunnel interfaces match up

I glanced over the debugs, you'd need the other side, too.

Like this was only have half the picture ;-)

As I said, you might want to open a TAC case, it's hard to troubleshoot those things on forums.

New Member

Re: Make tunnel interfaces match up

Tunnel 1 always comes up at each end and the RIP routing table fully converges. Tunnel 2 and 3 don't work however.

700
Views
0
Helpful
17
Replies
CreatePlease to create content