ASA AIP with 2 virtual sensors?

Unanswered Question
Jun 2nd, 2010

i'm green hand in deploying ASA AIP..

Anyone could let me know how to set the following requirements in ASA AIP?

Match "ACL1" then sig1 - drop

Match "ACL2" then sig1 - allow

this requirements seem need 2 virtual sensors.. however, in ASA AIP, how to do this?

i saw the only way to override action is "high", "medium", "low" , etc..

did any way to set like above requirements?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
m.kafka Wed, 06/02/2010 - 15:51

Hi szekahungdanny,

There are basically two options to achieve this:

1) You already mentioned, create two virtual sensors, create two class maps maps and assign each class map a different sensor in the policy map. The virtual sensors would have different actions for the specific signature.

2) Have one class map and policy action "IPS" and duplicate the signature and assign different attacker/victim filters in the signature definitions.

Hope that helps, rgds, MiKa

szekahungdanny Wed, 06/02/2010 - 19:48

yes. but my difficulty is how to add interface into that virtual sensor..

i just saw interface g0/1 only from IDM.

Jennifer Halim Thu, 06/03/2010 - 03:38

You would need to assign the traffic that you would like to direct towards 2 different virtual sensors via the policy-map configuration on the ASA, not via the AIP module configuration itself. You would need to configure the virtual sensor first on the AIP module, then you can choose which virtual sensors to send the traffic to via the ASA config.

Here is the configuration guide for your reference:

Hope that helps.

m.kafka Thu, 06/03/2010 - 04:52

Hi szekahungdanny,

sorry, I didn't understand what exactly was confusing you. You don't need to create a new interface pair on the AIP-SSM for a second virtual sensor, the packets destined for a specific sensor will be tagged on the internal interface of the ASA. The syntax for your service policy would be:

ips {inline | promiscuous} {fail-close | fail-open} [sensor {sensor_name | mapped_name}],

this allows traffic from different class-mapsto be sent to different virtual sensors (the mapped name is only relevant for multiple context, if the virtual sensor is mapped to a context-specific name).

But are you sure you want to have two virtual sensors just because of a different action of a single signature? That's not the design goal. The draw-back of two virtual sensors is, that you will have two class maps and you must duplicate every action on both traffic classes (like inspect etc) within your policy map.

Remember: a policy map is much like a switch/case/break construct of programming languages. Once a class matches only the actions of that class are executed, subsequent classes are ignored:

Translated to "C" a policy map would be:



            case 'match-criteria-class-1':



                       IPS inline fail-closed sensor vs0

                       inspect something

                       QoS settings



            case 'match-criteria-class-2':



                       IPS inline fail-closed sensor vs1

                       inspect something

                       QoS settings



Hope that helps understanding the issue, rather duplicate the signature in your existing sensor and edit traffic filters within the signature.

Best regards,


szekahungdanny Thu, 06/03/2010 - 09:09

ManyThanks to all...

i know using class-map into vs0, vs1...

but ..what i can't understand is .... when i create vs1, there're no interface could be selected.

in default "vs0", there're 1 interface gigaethernet 0/1.0 (blackplane)... how come no interface in vs1.

Now, I dump 2 pics . to explain what i difficult mean..

m.kafka Thu, 06/03/2010 - 16:26


szekahungdanny wrote:

ManyThanks to all...

i know using class-map into vs0, vs1...

but ..what i can't understand is .... when i create vs1, there're no interface could be selected.

in default "vs0", there're 1 interface gigaethernet 0/1.0 (blackplane)... how come no interface in vs1.

Now, I dump 2 pics . to explain what i difficult mean..

that should be perfectly OK, see:

AIP-SSM and Virtualization

AIP-SSM has one interface, GigabitEthernet0/1. When you create multiple virtual sensors, you must assign this interface to only one virtual sensor. For the other virtual sensors you do not need to designate an interface.

and further:

Follow this sequence to create virtual sensors on AIP-SSM (and to assign them to adaptive security device contexts):

1. Configure up to four virtual sensors on AIP-SSM.

2. Assign the AIP-SSM interface, GigabitEthernet0/1, to one of the virtual sensors.

3. Assign virtual sensors to different contexts on the adaptive security device.

4. Use MPF to direct traffic to the targeted virtual sensor.

I hope that helps how to handle multiple virtual sensors on the AIP-SSM

Still the question is why would you go through that trouble if you can duplicate the signature and change the action depending on the source/destination address configured in the siggnature details?

Keep it as simple as possible...

Rgds, MiKa

szekahungdanny Thu, 06/03/2010 - 09:12

I need 2 set of signature actions, not only a signature of action.

Set A is using default signature

Set B is using custom signature which is no deny/drop actions, only Log actions

Jennifer Halim Fri, 06/04/2010 - 04:26

You do not need to assign the backplane interface to the new virtual sensor that you have just created. You just have to assign the interface to the default virtual sensor. It will by default send through the traffic from ASA through the backplane interface towards the AIP module. On the ASA, you can define which virtual sensor to send the traffic to.

Hope that clears the confusion.

m.kafka Thu, 06/03/2010 - 16:31

If you duplicate a signature you can define independent actions (log only, no drop or reset) for the duplicate that's the easiest solution. You don't need necessarily two virtual sensors for this simple task. Just create a second signature with the same definitions except for traffic filter (source and destination IP) and different actions.

PS: I just thought of a third possibility: adjust threat rating and use event action filters. You can subtract the actions drop and reset for events which are rated "low" as defined by the event action rule. See (scroll down for SDM usage):

Message was edited by: m.kafka, added event action filters


This Discussion