Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2386
Views
0
Helpful
17
Replies

Make tunnel interfaces match up

Jonathan Ridgway
Level 1
Level 1

‎02-28-2014 02:51 AM

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

Labels:
0 Helpful
17 Replies 17

Marcin Latosiewicz
Cisco Employee
Cisco Employee

‎02-28-2014 03:08 AM

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.

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎02-28-2014 03:28 AM

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.

0 Helpful

Marcin Latosiewicz
Cisco Employee
Cisco Employee
In response to Jonathan Ridgway

‎02-28-2014 03:34 AM

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.

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎02-28-2014 04:12 AM

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 ?

0 Helpful

Marcin Latosiewicz
Cisco Employee
Cisco Employee
In response to Jonathan Ridgway

‎02-28-2014 04:46 AM

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.

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎02-28-2014 05:06 AM

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 ?

0 Helpful

Marcin Latosiewicz
Cisco Employee
Cisco Employee
In response to Jonathan Ridgway

‎02-28-2014 05:14 AM

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.

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎02-28-2014 05:21 AM

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.

0 Helpful

Marcin Latosiewicz
Cisco Employee
Cisco Employee
In response to Jonathan Ridgway

‎02-28-2014 05:25 AM

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 :]

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎03-05-2014 05:03 AM

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

!

0 Helpful

Marcin Latosiewicz
Cisco Employee
Cisco Employee

‎03-05-2014 05:27 AM

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.

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎03-05-2014 05:36 AM

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?

0 Helpful

Marcin Latosiewicz
Cisco Employee
Cisco Employee
In response to Jonathan Ridgway

‎03-05-2014 05:46 AM

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 ;-)

0 Helpful

Jonathan Ridgway
Level 1
Level 1
In response to Marcin Latosiewicz

‎03-05-2014 06:42 AM

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.

0 Helpful
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:

Customers Also Viewed These Support Documents