[c-nsp] how to make ASA vrf-aware / remote-access client VPN

[Ge Moua]

C-NSP Wizards:
Our Cisco account team seems to be touting the ASA appliance (in a 
cluster configuration) as the preferred solution for remote access 
client vpn (IPSec & SSL); as such my question then is:

Is it possible to make an ASA be "vrf-aware"?

I will use vrf-aware IOS terminology to describe my goals:
* teminate remote access vpn client traffic on "outside" interface 
("front-door vrf")
* re-direct decrypted traffic to "inside" interface ("inside vrf") 
towards enterprise apps

I tried to use the "group-policy" vlan mapping feature on only achieved 
some success to redirect traffic out different
egress vlans/interface.

Here are my findings why the vlan-mapping feature on the Cisco ASA will 
not work in our environment (I stand by this unless Cisco have other 
means that I do know of that will achieve "vrf-aware" connectivity from 
the ASA):
* vlan map can re-direct traffic out egress vlan (only at layer 2)
* layer 3 routes still needed from the ASA for outbound traffic to 
egress vlan
+ asa only allowed one default route in routed, single mode
    * if this is to work for "vrf-aware" client vpn connection, I'm 
thinking a default route per egress vlan will be needed; I was not able 
to do this
* vlan mapping does work, but only for simple routing environments; not 
really geared for multiple VRFs that get connected to a MPLS backbone 
and border with BGP & OSPF inter-related workings

So I proceeded to consider a design that assume that the ASA will only 
do remote access termination and leave the "vrf-awarness" 
("vrf-enabled") capabilities to the underlying network; this is what I 
came up with:

vpn_host_1 <==> IP_Cloud <==> ASA_VPN-Pool-A <==> PBR_BlackBox <==> VRF_A
vpn_host_2 <==> IP_Cloud <==> ASA_VPN-Pool-B <==> PBR_BlackBox <==> VRF_B

* ASA strictly doing remote access ipsec/ssl client vpn termination; 
btw, this really simplifies the ASA config significantly
* ASA has ingress for client vpn termination & egress for decrypted traffic
* decrypted traffic handled by "black box" (in this case catalyst-3750 
running router code) that does "policy based routing" based on source IP 
of client vpn ip pools

pros:
* ASA relegated to doing only client vpn termination
* simplified config per components
* PBR moved to another box to facilitate "vrf-aware" client vpn
+ simple routing on the ASA
    * one default route
    * no dynamic routing required

cons:
* more equipment needed in addition to ASA
* downstream failure may not trigger a VPN cluster member to be down (as 
it should in my opinion); what is needed is something like BFD 
(bi-directional forward detect) or some form of more intelligent route 
tracking (this may yet be possible; I've got to think more about this)
* overall design complexity increase because "vrf-enabled" moved off ASA

At minimum, I think this design will work for our needs; this design 
assumes additional complex components that I like to avoid if possible 
(PBR on a "black box" device").

Let me know what folks think; I'd really appreciate any ideas or feedback.

** Note
Iif the ASA wias truly VRF-aware like it's IOS brethren then all of this 
extra complexity may be minimized.

Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services