We have a very odd situation, we have clients with HIPS 8, Windows 7. They have the Cisco Call Agent, and Cisco Supervisor for our call centers.
The ports are documented for the agents and supervisors, and the ports are allowed. Still the Supervisors cannot 'monitor' the calls occuring on the agents. The Supervisor communicates with the agents via the UCXX servers
We have gone so far as to-
Allow ALL traffic to/from the UCXX servers to the supervisors/agents
Allow ALL traffic from the Cisco Agent/Supervisor application/executables
Disable IPS (though nothing was showing on this anyhow).
Allow ALL traffic to/from Supervisor/Agents individually, to test if anything was passing directly between them.
Disable IP Spoofing and FTP inspection.
Regardless, Supervisor is not able to monitor calls on an endpoint with Agents. When we disable the firewall entirely, it will work. We cannot find any evidence that additional traffic is being blocked, nothing shows in the Debug logs. Yet, when we turn 'off' the Firewall in HIPS 8, everything works.
All logic tells me that since nothing else is being blocked, this should not be occurring. I'm grasping at straws, so if anyone has experience with the Cisco Call Agent and Supervisor software when using HIPS 8, please pipe in any data you have.
Curious if you found a resolution. I'm fighting a similar issue. Just to shed a little light on the way monitoring works. The the voice conversation is spanned from the voice (switch side) port on the Cisco phone over to the PC port so that the agent application can get the RTP voice traffic (both sides of the conversation). When the voice monitor is initiated from the supervisor, the agent apps simply streams the conversation to it. My background is in Cisco voice so I'm not as familiar with the McAfee product, however, working with our internal McAfee SMEs we were able to get one side of the conversation (far end). When we disable the firewall on the agent phone, the supervisor can hear both sides of the conversation.
If you've had any success in this, please let me know. It would be greatly appreciated.
Try using an "Allow Any/Any" ruleset. Multiple policy settings need to be changed, not just the Firewall Rules policy.
KB67055 – How to troubleshoot a network facing application,or traffic is blocked by Host Intrusion Prevention firewall
Section: Use the Any-Any rule
Problem was 2-fold.
#1 - due to various computer refreshes, our systems using the agent had multiple NICs (realtek, Intel, etc.) with various driver versions (yeah, I know.... I know...). The Cisco agent REQUIRES that Vlan tagged traffic pass up through the NIC so that it can properly span/listen/send on the data and voice Vlans. So we had some NICs which did NOT support Vlan tagging, and it stripped them before passing it beyond the NIC to the OS.
Depending on the NIC type and firmware version, we had to do any of the following
- disable VLAN and Priority in the nic settings (enabled, actually stripped the tags so disabling it let them pass up)
- use registry changes to allow VLAN tagging (mostly for the Intel chipsets). Check the wireshark forums ( http://ask.wireshark.org/questions/1983/vlan-capture-setup-for-intel-network-car d-on-windows and http://wiki.wireshark.org/CaptureSetup/VLAN for examples )
#2 We had to use the following rules
- allow VLAN tagged traffic (perhaps there is a better rule? But this traffic is the Spanned traffic so the Source/Destination was different than the host. So we basically had to account for its need to listen for packets not intended for the endpoint at all). We have HIPS 8, so its under ethertype 0x8100
- Allow other ports depending on the deployment of your UCXX systems. Different features require different ports. We only had to do a few other ports which we bound to the application itself (fingerprinting)
3000-3022, TCP to/from the UCCX servers
3100-3122 tcp to/from the UCCX servers and domain
any/any UDP to our SIP trunk address x.x.x.x/32
59000-59021UDP to any domain IP - this was for Call Monitoring and Call Barge.
Again, depending on what options you use, and how you run your UCCX (p2p client to client, or client to server) you'll need to check the documentation. But the VLAN's not passing was a big one.