Mailing List Archive: Cisco: NSP

how to make ASA vrf-aware / remote-access client VPN

Index | Next | Previous | View Threaded

moua0100 at umn

Nov 2, 2009, 9:51 AM

Post #1 of 10 (204 views)
Permalink

how to make ASA vrf-aware / remote-access client VPN

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

_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

rwest at zyedge

Nov 2, 2009, 11:48 AM

Post #2 of 10 (192 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

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
_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

rwest at zyedge

Nov 2, 2009, 12:04 PM

Post #3 of 10 (192 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

Ge,

Just wanted to add one more thing.

> * decrypted traffic handled by "black box" (in this case catalyst-
> 3750

I've had very poor performance using the 3750 for PBR functions, have you tried to push any load through it?

-ryan

_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

peter at rathlev

Nov 2, 2009, 2:10 PM

Post #4 of 10 (190 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

On Mon, 2009-11-02 at 15:04 -0500, Ryan West wrote:
> > * decrypted traffic handled by "black box" (in this case catalyst-
> > 3750
>
> I've had very poor performance using the 3750 for PBR functions, have
> you tried to push any load through it?

We're using a couple of 3560s for PBR with no problems forwarding 100
Mbps+. There's no CPU load from the forwarding itself. We haven't tried
actually pushing it yet but are planning to try sometime soon.

The 3560 needs the "routing" SDM template for this to work; I guess the
3750 also needs this.

--
Peter

_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

rwest at zyedge

Nov 2, 2009, 2:21 PM

Post #5 of 10 (188 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

> We're using a couple of 3560s for PBR with no problems forwarding 100
> Mbps+. There's no CPU load from the forwarding itself. We haven't tried
> actually pushing it yet but are planning to try sometime soon.
>
> The 3560 needs the "routing" SDM template for this to work; I guess the
> 3750 also needs this.

What IOS version? I definitely had the proper SDM template applied, it won't work otherwise.

-ryan
_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

sethm at rollernet

Nov 2, 2009, 2:54 PM

Post #6 of 10 (188 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

Peter Rathlev wrote:
> On Mon, 2009-11-02 at 15:04 -0500, Ryan West wrote:
>>> * decrypted traffic handled by "black box" (in this case catalyst-
>>> 3750
>> I've had very poor performance using the 3750 for PBR functions, have
>> you tried to push any load through it?
>
> We're using a couple of 3560s for PBR with no problems forwarding 100
> Mbps+. There's no CPU load from the forwarding itself. We haven't tried
> actually pushing it yet but are planning to try sometime soon.
>
> The 3560 needs the "routing" SDM template for this to work; I guess the
> 3750 also needs this.
>

As fas as I've heard, the 3560 and 3750 are basically the same thing
with the major difference being the stacking ports on the 3750. The NME
etherswitch modules also identify as a 3750.

~Seth
_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

tvarriale at comcast

Nov 2, 2009, 3:55 PM

Post #7 of 10 (188 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

Was the traffic being applied in the CEF path?

tv
----- Original Message -----
From: "Ryan West" <rwest[at]zyedge.com>
To: "Peter Rathlev" <peter[at]rathlev.dk>
Cc: "cisco-nsp" <cisco-nsp[at]puck.nether.net>
Sent: Monday, November 02, 2009 4:21 PM
Subject: Re: [c-nsp] how to make ASA vrf-aware / remote-access client VPN

>> We're using a couple of 3560s for PBR with no problems forwarding 100
>> Mbps+. There's no CPU load from the forwarding itself. We haven't tried
>> actually pushing it yet but are planning to try sometime soon.
>>
>> The 3560 needs the "routing" SDM template for this to work; I guess the
>> 3750 also needs this.
>
> What IOS version? I definitely had the proper SDM template applied, it
> won't work otherwise.
>
> -ryan
> _______________________________________________
> cisco-nsp mailing list cisco-nsp[at]puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

moua0100 at umn

Nov 2, 2009, 7:06 PM

Post #8 of 10 (179 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

I did some throughput testing with iperf while connected as an ipsec
clinets and seemed to get over + > 120 Mbs easily; I too was interested
in how far I can push the pbr on the 3750.

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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services

Ryan West wrote:
> Ge,
>
> Just wanted to add one more thing.
>
>
>> * decrypted traffic handled by "black box" (in this case catalyst-
>> 3750
>>
>
> I've had very poor performance using the 3750 for PBR functions, have you tried to push any load through it?
>
> -ryan
>
>
_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

sethm at rollernet

Nov 2, 2009, 7:25 PM

Post #9 of 10 (179 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

Ge Moua wrote:
> I did some throughput testing with iperf while connected as an ipsec
> clinets and seemed to get over + > 120 Mbs easily; I too was interested
> in how far I can push the pbr on the 3750.
>

You should be able to push it to the platform's hardware limit as long
as nothing goes to CPU.

~Seth
_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

justin at justinshore

Nov 3, 2009, 11:20 AM

Post #10 of 10 (163 views)
Permalink

Re: how to make ASA vrf-aware / remote-access client VPN [In reply to]

Ge Moua wrote:
> 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"?

My suggestion may not be what you want to hear but I'll give it to you
anyway. Forget the ASA cluster and implement it on VRF-aware hardware.
You'll never see the end of problems with a cluster such as this and
it will be a nightmare for troubleshooting. It will cost you more up
front but it's worth doing it right.

We use 7600s with FWSMs and IPSec SPAs to provide firewall services and
VPN termination services to our Data Center. The FWSMs of course do not
do VPN, only firewall services. The IPSec SPAs have their own quirks
(see some of my earlier c-nsp posts) but they work fine once you know
how to avoid those problems. This solution doesn't so SSL VPN though.
The 7600s don't support the WebVPN module which is what you need for SSL
VPN. However the 6500 does and also supports the FWSMs and IPSec SPAs.

On a lower-end scale you can provide the same VPN services on ASRs,
7200s and even ISRs without having to fight the ASA nightmare. I would
avoid the ASA solution at all costs. Duct tape is great until the
sticky gives up in the middle of the night. Baling wiring rusts too.
Stick with the right solution and you'll be fine.

My $.02 (pre-2008 dollars)
Justin

_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com