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.