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

[Ryan West]

Ge,

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

Will you be using split-tunneling?  If you set each of your internal dot1q interfaces to the same security level and do not enable same-security permit-intrainterface, I don't think you'll need the VLAN mapping.
 
> 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

In multiple context, VPNs do not work.  This is on the list of things to be added, but there has been no indication of when.

>     * 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

I used a 3560 for this role and just ran VRF-lite for each customer / enterprise app environment.

> * 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

That's currently the only role I have enabled for that pair.  Customer traffic is terminated based on group-policy mapping, with environment specific AAA servers referenced.  For the SSL-VPN traffic, I had to create a number system matching kludge where each customer had a 7 digit number that corresponds to their environment, which they select during logon. 

> * 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

You should be able to get 24 VRFs on that box IIRC.
 
> 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
> 

Thanks,

-ryan