LCS - TCP Secondary connections and Messenger through a firewall (TCP or TLS)

----------------------------------------------------------------------------------------------------------------------------

Updated April 29, 2005

New subject as I will post another entry that is more specific to the Windows Messenger client and port usage for its features.

----------------------------------------------------------------------------------------------------------------------------

 

Customers using Windows Messenger to connect through a firewall will find this post informative. Please be advised that it is written based on a customer issue with WM5 and LCS 2003.

The issue below was a real customer issue and has a symptom that not all will experience, more likely they will fail to sign-in at all. I am posting this as is because it was a rather good problem summary report.

Reported Problem:
Users could not connect to Live Communications Server with 6 or more contacts in the list. They would receive the error: Signing in to SIP communications service failed because the service is temporarily unavailable. Please try again later.

Actual Problem:
The number of contacts was not the issue but the client server attempting to establish a secondary connection (ephemeral port range above 1024) through a firewall. The firewall saw the particular port range which was defined to be traffic type to disallow.

Recommendation:
TLS
TCP is not secure

Information for TCP implementation (info is aggregation of all who were involved with issue)
Windows Messenger and Live Communication Server will use a secondary connection and this can be controlled through group policy. If the server is listening on TCP, then the client will use a dynamic (source) port on the client, connecting to the (target) 5060. At the same time the client may specify a dynamic port in the registration Contact header indicating its listening port. Consequently server has no choice but to connect back to this port since SIP requires in-dialog messages to be delivered to the location specified in the Contact header. The firewall MUST allow this port for SIP/TCP logons to work, and hence the group policy applies to this port in particular. The server's source port for outbound connections is picked by WinSock and ranges between 1024-5000. Again this connection is only for SIP traffic.
Additionally, size of a message has no impact on whether the server opens a new connection or not – As mentioned above, the server opens a new connection if the Contact header in the registration requires it to.

Specify dynamic port ranges
Disabled
By default, the client application (for example Windows Messenger) will use a randomly selected port between 1024 and 65535 for SIP signaling and media traffic. When enabled, it allows for specifying the minimum and maximum port addresses used for dynamic port allocation. Default is 7100 minimum and 7103 maximum for SIP traffic; 5350 minimum and 5353 maximum for media.

The port range is configured by the system administrator. The values for the port ranges can be set in the registry under the registry key HKLM\Software\Policies\Microsoft\Windows\RTC\PortRange.
The ‘MinSipDynamicPort’ and ‘MaxSipDynamicPort’ values are used for setting the port range for SIP signaling traffic.
The ‘MinMediaPort’ and ‘MaxMediaPort’ values under the above registry keys are used for setting the port range for Audio/Video RTP and RTCP traffic.

No matter the communication is TLS or TCP, if the clients want to do file transfer, A/V, communication, they will negotiate a set of dynamic ports to use for the file transfer or RTP. These will be dynamic on both sides of the communication.

We can use registry setting to limit the range of dynamic port the client software use for communication, but we can’t really control exactly which port to use.

Source port is not a security concern. We know the server only listens to port 5061 (or other selected port) if we use TLS connection. If one is really concern about security, they can actually close all ports except port 5061 and IM will still work. (That is assuming they have other NIC/access to the server for administration and necessary infrastructure access.)
We can limit the client range of dynamic ports for A/V file communication.
If there is any firewall between/in front of the client, it can effective block all dynamic ports traffic, so dynamic port will not be an issue. TLS IM will still work, only advance communication fail.

Toml LCS Kid