Mobility Remote access requires both TCP and UDP


Configuring protocols on the ShoreTel Mobility Router (SMR) for Secure Remote Voice (SRV).
This affects all versions of the ShoreTel Mobility Router Administrator’s Guide.  For example, in the 4.7 version, page 6-10 in section 6.4 "Configuring Protocols" states:

"You can enable one or both of these security protocols. By default, DTLS and TLS are enabled.
If your network environment does not allow incoming UDP packets, you can use TLS, which allows TCP packets. If DTLS and TLS are enabled, DTLS is used first, and then TLS is used, depending on what the client supports."

And page 6-12:

NOTE: We recommend that TLS always be enabled so that remote provisioning can work correctly and for situations where UDP packets are not allowed in the network environment.

ShoreTel Mobility clients (SMC) in situations where remote access is needed will be connecting using Secure Remote Voice.  Whether via cellular-data or remote WiFi connection, the connection will be established using the remote port (default 443).
The SMR Administrator’s Guide states that only TLS is required.  This was (and is) the case for Nokia clients, but none of the other clients.  All other Mobility clients require both TCP (TLS) and UDP (DTLS) connectivity.
This means that both TCP port 443 and UDP port 443 must be open on the remote IP address, through the firewall, to the eth1 port on the SMR.


Everything looks normal until you make a call. When you place a call or answer a call, the call will either drop or have no audio. Often this is because TLS is enabled and working, but DTLS is either disabled or UDP is blocked. Different clients exhibit different behaviors.


TCP 443 and UDP 443 blocked somewhere between client and eth1 (Remote) port of SMR.


This document shows how to verify traffic flow is blocked or open. Often the changes required are in the customer network, such as a firewall configuration or VLAN setting; in other cases, SMR configuration needs review.


On the SMR, enable Remote Access logging to "Debug4".  (Configuration > System > Logging/Monitoring > Logging).  Then go to Troubleshooting > Mobility Router Logs.  Select the drop-down for "Remote Access", then click on "View Continuous".  This will open a new browser window and "tail" the Remote Access log.

A TCP packet sent from portQry and received at the Remote Access log has all zeroes in it, so all the IP addresses displayed will show "".

User-added image

A UDP packet sent from portQry and received at the Remote Access log will show as "Received 21 bytes" followed by "Discarded 21 bytes".

Discarded 21 bytes from unknown peer <Internet_IP_Address>:<Port> - Unexpected Content-Type 80

That way, we can conclude that UDP 443 is opened in the firewall from Internet-to-SMR direction. 
The following illustration of the UI version of the portQry tool shows that BOTH packet types are being sent.  It works best to send one, the TCP packet through, to verify that it is making it.  Then, send the UDP packet through.

User-added image

If using the command-line tool, from the command prompt use:

portqry -n -p udp -e 443

Where the value after -n is the Public IP address into the firewall.  This is the same IP address you would provide to users for Remote Provisioning.  443 is the default port.  Use the port that you configured on the Mobility Router.

Article: 000002261