VRF-Aware IPSec - Overlapping Subnets

[jacob.hengel]

Hey guys, have been trying to find a similar config or another thread with a working solution but have been struggling to wrap my head around a concept I have a fairly urgent need for a solution on. We have a couple racks in a colo-cage and provide some misc. managed services to our clients. Have a need for full VPN connectivity to some of our clients whom commonly utilize the same private subnets as each other. Because of the range of services we provide, need to be able to have bi-directional traffic between our equipment in the colo (that we have full control over) and their firewall/router at their location that we tend to have little control over. We provide each client with a unique vlan on our side (usually a /28 to accommodate a few VM's each) but many of our client's utilize other MSP's or in-house folks to manage XYZ edge appliance they have.

Since we have many devices behind customer's network and many devices they need to access bidirectionally behind our colo network, we are not interested in the massive amount of source-nat configs needed to make things work in that manner. My initial thought was to utilize VRF-Aware IPSec on our ISR's (we are Cisco exclusive) and utilize VRF's with VTI's and maybe some policy-routing (if needed, didn't get that far down brainstorming) to send traffic down the right VPN tunnel. However, many of our clients have security appliances that aren't Cisco or don't support GRE tunnels, etc to make how I had imagined it to work. I would need to be able to advise the client to have their appliance create a generic IPSec tunnel to one of our public IP's and pre-determine PSK+hash+encryption and let them know what their dedicated private network range is in our colo.

I have attached an overly-simplified diagram of what I am referencing. Class A addresses represent public IP addresses, class B addresses represent private IPs that we have the say to determine the ranges on (in our colo so we don't have to worry about overlap) and class C addresses represent private IP addresses the clients have pre-determined and that I cannot adjust (this is where the "distant" IP overlap comes in).

Hope someone has been there/done that or has any idea how to make this work.

Thanks in advance!

[Philip D'Ath]

This bit is crucial.

Does the "red" customer network only need to access the "red" network at your DC, and the "blue" customer network only need to access the "blue" network at your DC?  And these coloured networks don't need to access any shared network?

If so, you can exclusively use VRFs.

[jacob.hengel]

You are correct Philip, I do not need any communication between the two VRF's/clients and there are no shared subnets for them in the colo. The client's generally have VM's dedicated to them that we isolate onto their own dedicated VLans.

[Masoud Pourshabanian]

Hello,

As far as I know, VTI is not a GRE tunnel and it should work with generic IPsec. Have you tried it in a lab?

Masoud

[jacob.hengel]

Sadly, I have been getting yanked into project after project for the last couple months and by the time I get to my needed R&D time; my brain refuses to simply compute much other than what it already knows. Trying to brain-storm on how to make this work without an example to translate over has me running in circles lately and it is driving me bonkers.

I did find this link earlier:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html

And you are certainly correct; I believe that using the commands:

tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI

instead of the GRE commands on the tunnel interface is more along the lines of what originally had in mind.

[jacob.hengel]

I think Philip likely went the crypto map right since VTI to CM based VPN is hit or miss at best depending on the vendor on the client side. The configuration seems perfectly straight-forward from the VTI standpoint but without the guarantee of an IOS based device at the other end; crypto map style configuration is a lot more likely to work with vendor XYZ IPsec.

[Philip D'Ath]

Basically you need something like the below.  Vlanxx is the internal hosted subnet.  Gigabit0/0 is the interface facing the internet.  a.b.c.d is your outside IP address.

ip vrf client1

interface Vlanxx
 ip vrf forwarding client1
 ip address ...

crypto keyring kr-client1
 pre-shared-key address <client vpn concentrator> key xxx

crypto isakmp profile isakmp-client1
 vrf client1
 keyring kr-client1
 match identity address <client vpn concentrator> 255.255.255.255 
 local-address a.b.c.d

crypto map cm-cryptomap xxx ipsec-isakmp 
 set peer <client vpn concentrator>
 set transform-set ...
 set isakmp-profile isakmp-client1
 match address xxx
 reverse-route remote-peer a.b.c.d static

interface GigabitEthernet0/0
 crypto map cm-cryptomap

[jacob.hengel]

Thanks Phil!

I believe I am following the logic but it seems more "simple" than I had imagined (this is a good thing). Could also be my drained brain from the long days and I completely missed something but we'll see. Depending what I have easier access to after normal working hours tomorrow, I am going to either lab this or test in QA. Topology is drastically simplified compared to production but this allows me to limit the number of devices needed for testing purposes.

Based on the diagram I attached in the original post, I am going to be testing with a config similar to the attached. I purged the fat and used the IP's from my original diagram for verification.

Cheers.

[Philip D'Ath]

That NAT config won't work like that.  Get just the VPN bit working first.

To provide Internet access as well you will have to NAT into the global VRF from each client VRF.

[jacob.hengel]

Good to know, I don't need NAT/PAT for this test so I can certainly just tear that portion out for now. Thanks for the heads up to avoid the stumble.

[jacob.hengel]

I had some issues getting this config to work Philip but looks like it is mainly my only option after crashing & burning on attempting to get a VTI based VRF aware IPsec tunnel up to a non-cisco device (cm based ipsec would have worked fine if my theory is correct). I will be back at troubleshooting to get this to work, not sure why it wasn't working first time around but looks like I need to get back at your method if I am going to stand any chance at this.

[Philip D'Ath]

VTI's seldom work to non-Cisco boxes.  You'll need to use crypto maps.

[stephenm]

What was the end result here?  Looking at a similar architecture.

[stephenm]

What was the end result here?  Looking at a similar architecture.