Troubleshooting Shotetel Communicator over GlobalProtect

[njoyzrd]

I am wondering if anyone has successfully setup Shotetel Communicator (softphone) using the GlobalProtect VPN client?  I am working with a company who up until last week was successfully using the Shoretel Communicator through their Sonicwall's VPN client.  Upon switching over to the Palo Alto with GlobalProtect, the softphone breaks.  Soem functions are working like chat/IT, directory services, etc., but the softphone fails to make/receive calls.

I'm hoping someone has solved this issue.

Thanks,

Brian

[VinceM]

Hi,

How are the Shotel session in your palo ?

Allow / Deny / Incomplete ?

Maybe  security rule are missing between your VPN zone and either DMZ or LAN ?

V.

[njoyzrd]

Policy is not the issue, I have any/any allow between the Shoretel servers and the GlobalProtect VPN zone.  I am also logging a deny all rule at the end of my rulebase and I am getting no logs for "deny" packets.  I took a Wireshark capture and noticed that the Shoretel server tries to ICMP (ping) the IP address of my GlobalProtect client and it comes back "Destination Unreachable (port unreachable)".  I can't imagine that a simple failed ping could be the issue, but is there a setting that specifically allows GlobalProtect clients to be pinged?

[jvalentine]

Are there any NAT policies between these zones?

[njoyzrd]

No NAT over the tunnel (between zones).  Everything else between the GlobalProtect client system and the internal networks communicates perfectly.  As I originally mentioned in my post, I have an any/any allow rule between the internal/trust zones and the GlobalProtect VPN zone.  I am almost certain that the issue is related to the Shoretel configuration, but the fact that it worked last week through the Sonicwall VPN and now it doesn't work through GlobalProtect forces me to troubleshoot the Palo Alto side.

[VinceM]

Hi,

look in software release, the 5.0.5 just arrive and in the RN there is:

49724—Users were experiencing delays connecting to video conferencing applications

because the firewall was initially classifying the traffic as unknown-udp and discarding it.

This issue was due to an error creating RTP/RTCP predict sessions in cases where the

application only announced one of the protocols.

Maybe can be good for you ?

Rgds

V.