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.
The default port is 443 for the SMR RAST Server's TCP and UDP port for TLS and Datagram TLS respectively. It is used for Secure Remote Access when ShoreTel RoamAnywhere clients are on remote Wi-Fi or cell data.
Transport will be using TCP (TLS) and UDP (DTLS) as configured. The typical configuration is to have the defined port for both TCP and UDP open through the firewall and directly to the Eth1 port on the SMR.
Note that the SMR is NOT a firewall. Best Practice is to have the SMR safely protected behind a strong, actively managed firewall.
One method to determine that the ports are open through the firewall and to get to the Mobility Router is to use “portQry”. Find details on this tool and how to download it at Microsoft’s KB site: http://www.microsoft.com/en-us/download/confirmation.aspx?id=24009 or the command line version: http://support.microsoft.com/kb/832919
Please note that in the following examples the results shown in the portQry tool are not so important as whether you see the results of the packet having made through to the Remote Access (RAST) log on the SMR.
The ping command sends a particular packet (icmp echo request) to a specific IP address of a target host. There is a small server monitoring that host’s interface for icmp. When it sees it, the server echoes the packet back to its originating point. Most ports on an interface do not have this echoing service and, thus, look as if they are non-responsive. For security, it is often best if a firewall is NOT responding to pings or other traffic unless it is specific traffic authorized by that firewall’s rules.
Note that this tool will help to verify one-way TCP 443 and UDP 443 connectivity from Internet to SMR. It does not “prove” that TCP and UDP traffic can return to the sender.
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 "0.0.0.0".
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.
If using the command-line tool, from the command prompt use:
portqry -n xxx.xxx.xxx.xxx -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.