ASA 55xx-x and CX blade

[paul snoep]

Hi,

Posting here as the answers seems hard to find and/or create even more uncertainty.

We are considering deploying an active/standby pair on ASA 55xx-x with the CX blade, in multi-context mode.

There are rumors the CX functionality only works from inside->outside, not from outside-> inside. This is unexpected.

Secondly, I have heard CX functionality has some hurdles when running in mulit-context mode.

My questions:

- Does the CX blade works both ways, or do you need to select a direction?

- What are the details of multi-context and CX blade?

- Any hint on what policy to install since its either internal ASA, or through the blade. If through the blade, you need to select a policy.

- What are the caveats running the CX blade?

- Any proper clear document in which the theoretical functionality is explained?

Many thanks

Regards

[erkostla]

- Does the CX blade works both ways, or do you need to select a direction?
You can apply a policy to all traffic, or you select a direction.

- What are the details of multi-context and CX blade?
A single instance of CX is used by all the contexts.  The MPF in each context determines with traffic is sent to the CX instance. The CX instance can use interface roles to determine which contexts a policy applies to.

- Any hint on what policy to install since its either internal ASA, or through the blade. If through the blade, you need to select a policy.
I don’t understand the question.  Can you please rephrase?

- What are the caveats running the CX blade?
This could be a long discussion.   If you want, we can set up a call.

- Any proper clear document in which the theoretical functionality is explained?
For customer facing, there is the user guide.   For internal,  there are the engineering design docs and a number of white papers.

!

[paul snoep]

I appreciate your reply, please find below my filtered addition.

CX blade working both ways = answered

CX blade and multicontext - complex, but answered

According to the engineers installing the ASA/CX, I need to define the policy. Since the CX can work both ways, what performance impact do I get? They say traffic flows either through the ASA or through the CX. This does not match your reply, as the MPF and the interface roles determine what is passed through the CX.

So, what is wisdom to configure on this box? Where can I find some examples or hints on the policy to install using the CX for traffic in both ways on such a box?

Caevats running the CX blade - I would like a call - to understand all of it

Theoretical functionality is not in the userguide. Any other way to resolve?

Many thanks

Regards

[Collin Clark]

What traffic gets sent to the CX is determined by your policy. I can't think of a reason why you want to filter/view/inspect traffic inbound. The CX is web filtering not IPS. The more traffic you send to the CX the poorer performance (IMO, upgrade to SourceFire). Here's a blog post I wrote on sending traffic to the CX. I hope it helps.

I thought I would post my configuration for sending traffic to the CX from the ASA CLI. In talking with TAC there are two schools of thought here; create a deny ACL blocking what you do not want filtered and then put a permit at the end or create a permit ACL with what you want filtered then a deny to prevent all other traffic from being sent to the CX. The latter makes more sense to me so that is the route I go.

First I create an object group with the internal networks. In this example I’ll be sending all private address spaces (per RFC1918) to CX.

object-group network RFC1918
description RFC1918 Private IPv4 Address Space
network-object 10.0.0.0 255.0.0.0
network-object 172.16.0.0 255.240.0.0
network-object 192.168.0.0 255.255.0.0

Now for the ACL. I’ll be sending any traffic that has an RFC1918 source address destined to anywhere on TCP port 80 or 443 to the CX.

access-list ACL-CX-FILTER extended permit tcp object-group RFC1918 any eq www
access-list ACL-CX-FILTER extended permit tcp object-group RFC1918 any eq https

Next we create the Class Map that we will be putting in the Policy Map. We tell the Class Map to look at the ACL we just created.

class-map CM-CX-FILTER
match access-list ACL-CX-FILTER

Finally we add the Class Map to the Policy Map.

policy-map global_policy
…
…
class CM-CX-FILTER   cxsc fail-open auth-proxy

Let's assume, for some crazy reason you would want inbound traffic to go through CX, you would change your ACL to something like-

access-list ACL-CX-FILTER extended permit tcp any any eq 80

access-list ACL-CX-FILTER extended permit tcp any any eq 443

This would more than likely bring the CX to it's knees and either crash or performance would be severely impacted. In other words, only do this if you want things to fail.