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
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.
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.
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.
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 ?
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.
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 ?
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.
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.
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 :]
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
!
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.
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?
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 ;-)
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide