You'll need the sensor licensed in order to install signature updates. They're pretty critical.
"whats the virtual sensor for ?"
In version 6, you can have a multiple virtual sensors. Each virtual sensor can have a unique signature policy, event action rules policy, and anomaly detection policy. You apply the virtual sensor to a physical or logical interface. Being new, I would recommend just working with the defaults for now (a single virtual sensor). Are you using the GUI to manage?
Gi0/0 on the SSM is the external management port of the SSM itself. This interface is where the SSM's own IP is assigned.
Gi0/1 on the SSM is the internal backplane interface. All packets from the ASA will come in this interface.
The Gi0/1 interface is what you need to assign to vs0.
You do not directly assign any of the 4 ASA interfaces to the virtual sensor.
Instead you create one or more policies on your ASA that contain an entry of "ips inline" or "ips promiscuous" for one or more classes of traffic.
You then assign the policy either globally, or to 1 or more interfaces of the ASA.
If an "ips promiscuous" policy is used then the ASA will send a copy of the matching packets to the SSM's internal Gi0/1 interface.
If Gi0/1 is asssigned to vs0 then these copied packets will be monitored by vs0.
If an "ips inline" policy is used then the ASA will send the actual packet to the SSM's internal Gi0/1 interface. Where it will then be monitored by vs0 (assuming Gi0/1 was assigned to vs0). If no attack is detected then the packet is sent back to the ASA through Gi0/1 where the ASA can then complete whatever is needed and send on to the destination host. If an attack is detected, then depending on the sensor configuration the packet can be denied/dropped by the SSM in order to prevent attack packet from getting to the end destination machine.
With ASA version 7.2.x, you are limited to using a single virtual sensor on the SSM (vs0).
With a future 8.0 version of the ASA (not yet released) you will gain the ability to use multiple virtual sensors on the SSM (with IPS 6.0 on the SSM).
In that future version the "ips promiscuous" and "ips inline" configuration entries in the ASA policy have an additional "sensor " configuration option.
When this option is used the traffic would be sent to a specific virtual sensor that you name instead of vs0 where you assigned Gi0/1.
The packets would still be sent to the SSM on Gi0/1 but the ASA would append a special header to tell the SSM to monitor them with a specific virtual sensor instead of vs0 (unless of course you specifically named vs0).
Alternatively in 8.0 you coudl instead assign a virtual sensor to a context as it's default virtual sensor. Then all "ips inline" and "ips promiscuous" entries in the policies for that context would automatically send their packets to a specific virtual sensor without having to add "sensor " to the end of each context. It is sort of a short cut.
So what is a recommendation for the beginning user.
1) Go into the SSM CLI and run the setup command. When you come to the option for configuring virtual sensors you simply assign Gi0/1 to vs0.
2) Modify your existing ASA policy that is assigned globally. For each class of traffic that you want monitored add in the following configuration entry into the policy:
"ips promiscuous fail-open"
A Promiscuous policy is always best for beginners to tell you gain a better understanding of the SSM IPS code. Then later change it to an InLine policy.
The "fail-open" on the end tells the ASA to continue to pass traffic even if the SSM fails.
The other option "fail-close" would tell the ASA to not pass the traffic if the SSM failed. It only gets used in high security environments with mandates that all traffic must be IPS monitored before transmit. This is usually not the case in most commercial business environments.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...