Troubleshooting Shotetel Communicator over GlobalProtect

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Troubleshooting Shotetel Communicator over GlobalProtect

L1 Bithead

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.




L5 Sessionator


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 ?


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?

L7 Applicator

Are there any NAT policies between these zones?

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.

L5 Sessionator


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 ?



  • 5 replies
  • 101 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!