I have a 5520 running 7.2(4) (Routed, single context) with an SSM20 running 6.1(1)E2.
I am struggling a bit with the SSM setup on my 5520. I have created 2 service policies, one applied to a DMZ interface and configured as "in-line". The other applied to the inside interface and configured "promiscuous" (until I get it tuned).
It appears there is no way (on 7.2) to direct each service policy to its own virtual sensor on the SSM20. For this reason I am struggling a bit in trying to determine which Service Policy is sending the traffic that triggers a particular event. Is there anything in the SSM event log that identifies which Service Policy sent the traffic to the virtual sensor?
Thanks in advance!
The ASA does not tell the SSM which policy sent the packet, so the SSM can not report which policy sent it. Only whether to monitor it promiscuous or inline (and in the case of 8.0 which context it came from and which virtual sensor to use).
Other things that might help.
Look at the addresses of the alerts.
If the source address is a DMZ address, then likely the DMZ policy.
If the source address is a Inside address, then likely the Inside policy.
If the source address is a Outside address, then look at the destination address.
If the destination is a DMZ address, then likely the DMZ policy.
If the desintation is a Inside address, then likely the Inside policy.
In the case of TCP, the SYN packet will determine which policy will affect the rest of the packets.
And it is the first ips policy that matches which will determine the type of monitoring.
So a SYN packet coming FROM the DMZ TO the Internet will first be checked by the DMZ policy. So if the DMZ policy matches, then it will be inline monitored (by the DMZ policy).
Similarly a SYN packet coming FROM the DMZ TO the Inside will first be checked by the DMZ policy then it will the be checked by the Inside policy. If the DMZ policy matches then the SYN and remaining packets for the connection will be inline monitored. If the DMZ policy matches, then the Inside policy will still be checked, but it is the DMZ policy that will determine promiscuous or inline because it is the first policy matched. If the DMZ policy does NOT match the SYN packet, but the Inside policy does, then the connnection will be Promiscuously monitored by the Inside policy.
In reverse, however, a SYN packet FROM the Inside TO the DMZ will be firt matched against the Inside policy.
The inside policy matching first would cause the connection to be monitored Promiscuously. The DMZ policy woudl be checked, as well but with the Inside policy matching first it will cause the promisuous monitoring.
Only if the Inside policy is NOT matched would the a DMZ policy match cause Inline monitoring.
At least this is is how I think it worked back in 7.2. The above is how it does work in 8.0 when we tested with virtual sensors, and so I assume it worked that way back in 7.2 as well.
In your alerts above. The first alert has "Actions droppedPacket+deniedFlow+tcpOneWayResetSent " the Deny/Drop actions can only work in Inline mode, so it must have come from the DMZ policy.
The second alert has "Actions denyPacketRequestedNotPerformed+denyFlowRequestedNotPerformed " and the "NotPerformed" for the Deny/Drop actions generally only happens with Promiscuous mode. So it must have been from the Inside policy.