ASA 5512 different route per VPN group (VRF like functionality?)

[Denis Pointer]

Hello,

Here is what I am trying to do.  i have an Nexus 7000 with several VRF's, for simplicity lets call it VRF A, VRF B, and VRF C. VRF A is simulating a management network, and VRF B and C are customer environments.  VRF B and VRF C will have IP overlap.  I have an ASA 5512 I am using to VPN into the environment, this is also providing internet access for the applications running in VRF A, (VRF B and C do not require internet access).  What I want to do is set up three different VPN accesses on the same ASA, where some users will have VPN 1 group policy and have access to VRF A, but should not have access to VRF B or C, likewise VPN 2 should have access to VRF B, and VPN 3 to VRF C.

My initial intention was to configure the ASA with Gig 0/0 to internet, Gig 0/1 to VRF A, and then Gig 0/2 sub interfaced so 0/2.10 is 10.10.10.1 in VLAN 101 which connects to VRF B, gig 0/2.11 would be 10.10.10.1 in VLAN 102 which connects to VRF C.  However, best I can tell ASA 5512 is not VRF aware (or is there just a separate license I would need?) and as such this isn't possible.

Next thought similar process, but instad configure as 0/2.10 is 10.10.10.1 in VLAN 101 which connects to VRF B, gig 0/2.11 would be 10.10.11.1 in VLAN 102 which connects to VRF C. However, I still run into issues here, as both VPN 2 and 3 need to access devices with the same IP address, again best I can tell, the ASA is not capable of doing Policy based routing.

Is there another way to achieve this? Is there something I am overlooking?
I need to ensure that users on VPN 2 can only access services available in VRF B, they should not have the ability to access (intentionally or otherwise) servives on VRF A or C, nor users on VPN 1 or 3.

I also have an ASA 5585 w/ multi context license, which I can then create a context per VRF (which I already have), I then have interfaces in each context connected to the correct VRF.  However, I don't beleive I can terminate VPN here, as best I can tell when in multi-context mode you can not have VPN license.

[Marvin Rhoads · Accepted solution]

Your research led you to correctly conclude that the ASA is neither VRF-aware nor can it do policy-based routing. Also, you cannot terminate remote access VPN on a multi-context ASA.

So doing what you ask with a single ASA is a bit problematic. If you had unique internal addresses, the subinterfaces would work fine.

Since it sounds like you have a virtualization infrastructure, have you considered using the lower cost ASAv? You could spin up multiple instances, one per VRF. Each knows only about the public address space and its respective assocated VRF.

[Denis Pointer]

Hello Marvin, thanks for the response.

I did think about the ASA 1000v briefly, but when I found release notes for what I thought was new version (turns out this is a couple year old version, from 2012: http://www.cisco.com/c/en/us/td/docs/security/asa/asa87/release/notes/asarn87.html ) it it listed VPN remote Access as not supported "Includes Remote Access, Clientless (SSL) Access, Multi-site (SSL) Access, Easy VPN on the ASA 5505, VPN Phones, AnyConnect Essentials, and AnyConnect Mobile.)"

Looking again I found newer release notes and it does look like it has since been added in as supported?

The other option I was looking at this morning was using something like an ASR 1000 for the IPSEC site-to-site VPN tunnel, then a separate ASA as needed for user access, but I'll have to give the ASA 1000v a closer look for sure.

[Marvin Rhoads · Accepted solution]

Denis,

Note the ASAv is a different product that the ASA 1000v. The latter is positioned as an internal data center firewall and thus it does not support the features your noted.

The ASAv was just released a couple of months ago and it does indeed support remote access VPNs. As noted on its data sheet, "Cisco ASAv supports site-to-site VPN, remote-access VPN and clientless VPN functionalities as supported by physical Cisco ASA devices."

It is targeted at use cases such as yours.

[Denis Pointer]

Thanks again, I missed that, while one of the documents I was looking at was the ASAv i didn't realize that was a different product.