Windows Messenger in Windows XP: Working With Firewalls and Network Address Translation Devices
This article discusses several scenarios describing what you need to use all the Microsoft Windows® Messenger features and provides possible solutions to identified issues.
By using Windows Messenger service, you can communicate with your contacts by instant messaging (IM), voice, video, application and data sharing, and remote assistance. In many networks, all of these features can be used without any changes to the network infrastructure. However, there are networks that require special configuration for all of these Windows Messenger features to work.
Microsoft is committed to working with industry leaders and standard organizations such as the Internet Engineering Task Force (IETF) to make sure that this rich communication and collaboration capability is available behind firewalls and network address translations (NATs).
On This Page
NAT and Firewall Issues
NAT and Windows Messenger
Firewalls and Windows Messenger
Windows Messenger Configurations: What Works and What Does Not
Audio and Video with Microsoft Internet Security and Acceleration (ISA) Server
Glossary of Acronyms Used
Ann Demirtjis, Lead Program Manager, Microsoft Corporation
Imad Yanni, Product Manager, Microsoft Corporation
Michael Kessler, Technical Editor, Microsoft Corporation
This article discusses several scenarios describing what you need to use all the Windows Messenger features and provides possible solutions to identified issues.
Windows Messenger provides an exciting real-time communication experience. By using Windows Messenger, you can communicate with your contacts by IM, voice, video, application and data sharing, and remote assistance. In many networks, all of these features can be used without any changes to the network infrastructure. Certain networks, such as business or residential, can also deploy firewalls and/or NAT components.
The purpose of a firewall is to protect computers on the network by blocking direct access to them. Computers behind a firewall use a NAT component to share limited public Internet Protocol (IP) addresses. Sharing IP addresses is a limitation imposed on the Internet by the current IP version 4 (IPv4) addressing scheme. Because the IPv4 addressing scheme is not able to provide enough IP addresses, the information technology industry was forced to standardize NAT and deploy NAT products that share IP addresses and Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ports. As a result, some Windows Messenger features—mainly instant voice and video communications—experience reduced functionality when used in certain Internet scenarios.
When universal plug and play (UPnP)–enabled firewalls or NAT components are used between communicating parties, all of the Windows Messenger features work as intended. However, there are network setups that require special configuring for all of the Windows Messenger features to function.
Note: Microsoft is committed to working with industry leaders and standard organizations, such as the IETF, to make sure that this rich communication and collaboration capability is available behind firewalls and NATs.
NAT and Firewall Issues
This section explains the Windows Messenger features affected by NAT and firewall issues: Instant Messaging and Presence information, Audio and Video, Application Sharing and whiteboard, File Transfer, and Remote Assistance.
Windows Messenger provides the ability to communicate using text, voice, and video; collaborate by transferring files; and share applications and whiteboard drawings.
There are a number of configurations in which all the capabilities of Windows Messenger work seamlessly. And there are also configurations where certain capabilities are limited or do not work. To resolve some of these issues, Windows Messenger uses the UPnP infrastructure in Windows XP and earlier versions of Windows. This type of resolution becomes more available as more Internet gateway devices add support for UPnP.
Note: Microsoft is providing support for UPnP in its Internet Connection Sharing (ICS) and Internet Connection Firewall (ICF) technologies for Windows XP. For more information about Internet Connection Sharing and Internet Connection Firewall, read What’s New In Security for Windows XP.
The following Windows Messenger features affected by NAT and firewall issues are:
Instant Messaging and Presence Information
In general, there are no issues with IM and Presence information affecting communication through a firewall or NAT device. If the Windows XP client can create and maintain a connection to the server, other IM and Presence communication can follow this same path. For example, Microsoft Exchange Server IM transports its Presence and IM messages using hypertext transfer protocol (HTTP) and has mechanisms to insure that these messages can traverse firewall and NAT devices. These mechanisms include polling to maintain a TCP connection to the server for two-way communication and setting aside a fixed port for callback delivery.
When a session initiation protocol (SIP) solution is used, the data may be sent using TCP, UDP, or Secure Sockets Layer (SSL). SIP signaling can also use dynamic ports, which may require opening the entire range of ports on a firewall. If a NAT device is placed between SIP clients and their servers, differences can exist between the ports and addresses reflected in the SIP messages and the actual ports and addresses. Windows Messenger has mechanisms to overcome these issues and they are discussed later in this article.
Audio and Video
When negotiating an audio-video session, dynamic ports were chosen for the audio-video (AV) stream. Dynamic ports are used to enable the application to work regardless of what other applications are running on the system and using port resources. In the case of Microsoft .NET Messenger Service, the session invitation was sent by station B to the address it received for station A.
The following issues might arise if a firewall or NAT were present in these scenarios:
The address provided by A in either the session invite for session signaling, or in the session acceptance for the UDP streams, might be an internal address that is translated by a NAT device—an invalid (or fake) address for B to use to contact A. In other scenarios with the 4.5 client, A might initiate the session, but the same or similar addressing issues exist.
When B sends the session invitation to A, this invitation is sent using the IP address and port passed from A to B. For this to work, this port must be enabled to pass through any firewall between A and B.
The actual Real-time Transport Protocol (RTP) streams are sent using dynamically allocated UDP ports in the range of 5004–65535. Without a way to open these UDP ports on any firewall in the path dynamically, the streams fail to reach their destination.
Application Sharing and Whiteboard
The following issues arise when using application sharing and whiteboard in a NAT or firewall environment. (The first two issues are the same as found with audio and video.)
The address provided by the initiating station might be an internal address that is translated by a NAT device. This is an invalid address for the external client to use to initiate the SIP session or TCP connection to A.
The port used by the external client to send the SIP invitation—passed to the external client by the internal client—must be enabled to allow the SIP invitation to pass through any firewall between the clients.
The TCP connection for the application sharing (AS) and whiteboard (WB) data uses port 1503, which needs to be enabled to traverse any firewalls. This is not true in the case of a UPnP-enabled gateway, which maps the internal static port to another port.
Since a specific port is used for the TCP data connection (1503), if the client is behind a non-UPnP NAT device, the port must be mapped to that client. This ensures communication through the least common denominator NAT device. This also means the port cannot usually be used by another client behind the NAT device; only a single client behind the same NAT device can have an AS or WB session active.
File Transfer (FT) requires that the initiating station pass its address to the FT peer in the session exchange through the server. Because of this, the first issue listed under application sharing and whiteboard applies:
The address provided by the initiating station might be an internal address that is translated by a NAT device. This is an invalid address for the peer to use for the TCP connection.
The TCP connection for file transfer, which could be initiated by the external party, presents an additional issue.
Both incoming and outgoing TCP connections use the range of ports from 6891–6900. This allows up to 10 simultaneous file transfers per sender. These ports must be open on any firewall between the peers. If you open only port 6891, users can only do one file transfer at a time.
Remote Assistance uses Remote Desktop Protocol (RDP); this is the same protocol used by Microsoft Terminal Services. RDP is built on top of a TCP connection. Windows Messenger sets up the remote assistance session using the server-based session invite logic—similar to File Transfer. Because of this, the issue with NAT addresses applies to this scenario as well.
Remote Assistance includes additional logic to deal with the NAT scenario. This logic simply attempts to create the TCP connection from both clients. This way, if one of the clients is behind a NAT, the connection can still be created and remote assistance occurs. If both clients are behind a (non-UPnP) NAT, the connection cannot be established. The additional SIP invite logic is only added if a voice session is added in support of Remote Assistance.
In addition to the issues resulting from NAT addresses, which are only of concern with multiple NAT devices in the communication path, TCP port 3389 is used for the TCP connection for the Remote Assistance protocol. This means that port 3389 must be opened on any firewalls between clients.
NAT and Windows Messenger
This section addresses issues and configurations for NAT devices.
Problems Caused by NAT Devices
The specific problems that NAT devices cause in relation to Windows Messenger features include:
Clients behind a NAT device usually have a private IP address assigned to them. This address is translated to and from a public IP address and port by the NAT device. In several cases this private address is presented in a message to a Windows Messenger peer to enable the peer to contact the client. The address is invalid for this use and the translated address must be used instead.
There are several cases where port mappings must be made at the NAT device to present an address and port to an external client and have it map to the appropriate internal client.
In some cases where static ports are used for a particular feature, only a single client behind the NAT can use that feature.
Working With Different NAT Device Configurations
The following section discusses issues related to different NAT device configurations:
UPnP-enabled NAT Devices
The UPnP forum contains several working committees, including a working committee specific to Internet gateway devices. This group is responsible for defining the specifics of UPnP support for these devices which include NAT and firewall devices. This group has defined a standard for ICS and NAT network traversal using UPnP.
NAT and firewall devices that support this standard can be detected and controlled using UPnP protocols. UPnP can be used by clients to read and configure port mappings. Windows XP ICS and ICF support this standard. Other vendors of network edge devices have also announced support of this standard, including ARESCOM Inc., Buffalo Technologies Corp., D-Link Systems Inc., Intel Corp., Linksys Group Inc. and NetGear Inc.
Windows XP also provides client support for UPnP and application program interfaces (API) specifically designed for applications to detect and take advantage of UPnP-enabled NAT and firewall devices on a network. Windows Messenger in Windows XP uses these APIs to achieve the following:
Detect whether the Windows Messenger client is behind a NAT device, and if so retrieve the translated address to send to its peer. This solves several problems seen above.
Obtain a port-mapping for dynamically allocated ports to be used for signaling, such as required by a SIP session configuration. This allows signaling by the external client to reach its destination.
Obtain mappings for the dynamic ports used by media streams–including those used for AV, AS, and WB.
Detect whether the Windows Messenger peer is behind the same NAT device. If so, the real addresses of the peer are retrieved and the peers can communicate directly.
Note: Support for UPnP clients of NAT traversal is currently available for previous versions of Windows—Windows 98, Windows 98 Second Edition, and Windows Millennium Edition. This support is distributed by running the Network Setup Wizard that ships in Windows XP.
Non-UPnP NAT Devices
Windows Messenger peers, separated by a NAT device that cannot be detected, should be able to use IM and Presence information. This is true whether the network service being used is .NET Messenger, Exchange IM, or a SIP solution. Clients using SIP servers also work because logic has been added to the client to ensure communication when the server is opened.
Issues arise, as described earlier in this article, with the other features of Windows Messenger. The following points relate to those issues:
IM and Presence information are implemented through a mediating server with a direct TCP connection initiated by the client when using .NET Messenger or Exchange IM. This should not present any NAT or firewall issues. Sessions or connections initiated by clients external to the NAT device do not succeed because the internal client cannot provide the NAT-translated address to the peer. In the case of AV, this applies to calls made by the internal client to the external client because the external client is the one initiating the SIP session. If the external client calls the internal client, the failure occurs later in the process. The internal client can send the SIP invite to the external client, but the address passed in this invite is incorrect.
Calls made between peers on the same side of the NAT device should work.
An application layer gateway (ALG) for SIP may alleviate some of these problems. ALGs can be used as an application level filter for specific applications and protocols.
Cascading NAT Devices
Even if the edge of your network doesn't use a NAT device, or uses a UPnP-aware NAT device, Windows Messenger AV communication can be defeated by a cascading NAT scenario. In this scenario, another NAT device exists in the path between you and the Windows Messenger client you are communicating with, and this NAT device is not under the control of either client. This can occur if your Internet service provider (ISP) also uses NAT technology in their network. This is not a common occurrence. If you suspect this situation, contact your ISP to verify the issue and discover possible workarounds.
Firewalls and Windows Messenger
Like NAT devices, firewalls can present problems when you’re trying to communicate using Windows Messenger. Problems introduced by firewall devices include:
The messages used for SIP signaling may come from an external client and seem to be unsolicited from either a dynamic port or port 5060. For these messages to make it to the Windows Messenger client, the ports must be opened on the firewall. For example, when using ICF on Windows XP, port 5060 is blocked by default.
Ports for media streams and other data, such as the dynamic ports for AV and port 1503 for AS or WB, must be allowed to traverse the firewall.
Working With Different Firewall Configurations
The following section discusses issues related to different firewall configurations:
UPnP-enabled gateway devices were discussed earlier in this article. The Windows XP firewall, known as the Internet Connection Firewall, is UPnP- enabled. Windows Messenger in Windows XP uses this capability by opening the ports required for signaling, connections or media streams.
Very few options exist for using the advanced features of Windows Messenger with a non-UPnP firewall. Points to consider on this topic include:
Peers on the same side of the firewall can use all of the features of Windows Messenger.
IM and Presence information work through most firewall configurations.
To support AV in both directions through the firewall, all UDP ports between 5004 and 65535 must be opened to allow signaling (SIP) and media streams (RTP) to traverse the firewall. This is required because dynamic ports are used. AS and WB also use dynamic ports for signaling.
File Transfer can be enabled by opening ports 6891–6900 on the firewall. Remote Assistance can be enabled by opening port 3389.
Cascading firewalls can cause problems similar to cascading NAT devices.
Limitations of UPnP in Windows XP
In Windows XP, outgoing calls from Windows Messenger do not function when ICF is enabled on the local interface and the user does not have administrative privileges. This feature functions correctly for users that have administrative privileges.
Note: Windows XP Home Edition gives users administrative privileges by default.
Windows Messenger Configurations: What Works and What Does Not
Presented here are several diagrams of Windows Messenger configurations using NAT and firewall devices. These illustrations are categorized by “Configurations That Work” and “Configurations That Won’t Work”.
Configurations That Work
The following configurations work—assuming network problems do not exist.
Single UPnP-enabled NAT
In Figure 1, Home "A" is equipped with a UPnP-aware Internet gateway device. Home "B" has a personal computer connected directly to the Internet and does not use a gateway device. The UPnP gateway allows Home “A” to be aware of its external network address and create mappings as needed. This allows Home “A” and Home “B” to communicate as shown in Figure 1.
Two Homes Connected Through UPnP-enabled Gateways
Figure 2 is similar to Figure 1, but in this case Home "B" contains an Internet gateway device. Since both devices are UPnP-aware, Home “A” and Home “B” can still communicate with each other using all of the Windows Messenger features as shown in Figure 2.
Two Clients Behind a UPnP-enabled Gateway
Figure 3 shows two clients behind the same edge device. If the NAT device is UPnP-enabled, the clients recognize that they are behind the same device and that they can communicate directly as shown in Figure 3.
Configurations That Do Not Work
The following configurations contain barriers to Windows Messenger communications other than IM and Presence information.
When the ISP Uses NAT
Figure 4 represents the scenario previously presented in Figure 1, but in this case the ISP used by Home "A" also employs NAT technology. This blocks Home “A's” computer from knowing its true public address as shown in Figure 4.
Home B Uses Non-UPnP NAT
Figure 5 is similar to Figure 2, but in this case the NAT used by Home "B" does not support UPnP and does not allow Home “B’s” personal computer to determine its translated addresses. This is illustrated as shown in Figure 5.
A Non-UPnP NAT
Figure 6 is the same as Figure 1 with the exception that the NAT is not UPnP-aware. Once again the translated addresses cannot be determined and port mappings cannot be created for the dynamic ports used by Windows Messenger. This is illustrated as shown in Figure 6.
When NAT or firewall devices are added in the communication path for Windows Messenger, various difficulties might arise. Nearly all of these issues are addressed through the use of UPnP-enabled Internet Gateway devices. Many vendors are already building this capability into their devices and some are even considering back-porting the capability to older, upgradeable devices.
The following summary of issues and solutions is provided here for easy reference.
The client behind a NAT device has a private address that can be used on the internal network and a public address, provided by address translation, for communication with the world outside of the NAT device. The protocols used to create AV sessions between clients include addressing information. The addresses provided can be private, internal addresses and port numbers, which may be invalid on the public network. This inhibits communication by voice and video
Workaround for NAT Issues
UPnP-enabled NAT devices enable Windows Messenger to negotiate the port numbers to be used and determine translated IP addresses. This allows clients to share valid addressing information and lets users communicate by voice and video through NAT-fronted networks.
Available NAT Solutions
Windows XP includes a UPnP-enabled Internet gateway in the form of ICS. This is a simple solution if a computer is used as the Internet gateway device. Other vendors are working on UPnP-enabled gateway devices or upgrades to add UPnP support to their current gateway products. For more information about these products, read Windows XP and Internet Gateway Devices to Enable Great Broadband Experiences on the Microsoft PressPass website and the vendors’ websites.
Other NAT device vendors may provide interfaces to create application layer gateways (ALG) or application filters. These are plug-ins to the device software written to support specific protocols or applications and translate the data as appropriate for internal vs. external networks.
Administrator/User Action Required
If you suspect a problem, ask your ISP or refer to the Internet gateway documentation to determine if NAT is used and whether UPnP support is available. If you are using a UPnP enabled NAT, consult your ISP on whether NAT is used in their network and whether there is a workaround that enables RTP-based AV.
Firewalls protect computers on the internal network by not allowing traffic to reach IP addresses and TCP/UDP ports that are not explicitly configured and enabled. Traffic is allowed based on outgoing requests for data or connections to allow normal, solicited communication.
With Windows Messenger, there are situations where the data path is configured on the communicating clients using session establishment protocols such as SIP. Once the session is configured, the communication may be initiated by the external client. This communication may be blocked by the firewall. Furthermore, Windows Messenger uses dynamic ports for AV traffic. This ensures available port resources for the AV streams, but further complicates the firewall issue because it is not known which ports are used.
Workarounds for Firewall Issues
The solution to these firewall issues is provided again by UPnP. Windows Messenger detects UPnP-enabled firewalls and configures them appropriately based on the current communication needs. If a UPnP-enabled firewall is not in place, the firewall must be configured to allow traffic on the protocol and ports necessary for the Windows Messenger functionality you desire. See Administrator/User Action Required, later in this article.
Available Firewall Solutions
The firewall provided with Windows XP—Internet Connection FirewalI—supports configuration using UPnP. Windows Messenger detects this capability and opens the appropriate ports to enable your communication to proceed. If you are using another vendor's firewall product, check the vendor-provided information to determine if UPnP is supported, or find out how to configure the firewall to allow the ports listed to pass. See Administrator/User Action Required in the next section.
Administrator/User Action Required
To enable voice and video communications with Windows Messenger through a non-UPnP firewall, configure the firewall to allow incoming traffic on UDP ports 5004 – 65535.
For other purposes, enable the following ports:
File Transfer: 6891 (to allow 10 simultaneous file transfers, open ports 6891–6900)
Application and Whiteboard Sharing: 1503
Remote Assistance: 3389
If you suspect a problem, consult with your firewall vendor and read available documentation to determine whether UPnP support is an option and how to configure the firewall to allow specific ports. Consult with your ISP if you suspect a cascading firewall issue.
Audio and Video with Microsoft Internet Security and Acceleration (ISA) Server
A special scenario occurs for AV when an ISA Server acting as a firewall and proxy server is deployed on the edge of the network and an SIP server solution is being used. How this scenario works depends on the location of the SIP servers in relation to the calling client.
The following two deployment scenarios illustrate this special situation:
Deployment 1: Using ISA Server as a Firewall and Proxy
In this deployment, station A is running the Windows Socket Proxy client and calls from station A to station B or from station B to station A succeed. This works because of the way Windows Messenger determines its local address.
This is done by using sockets to connect to a remote address and the SIP server and then asking sockets what local address was used. In this case, the address received is the address from the external interface of the ISA Server—Address X. This address and a random port are then sent to station B in the session invitation using the session description protocol (SDP).
When the call originates at station B, station A receives much information about station B. This information can be used, specifically station B's address, to determine what address station A should use in the response to the session invite (200 OK with SDP information), as shown in Figure 7.
Deployment 2: Using ISA Server
This scenario is slightly different; calls from station A to station B never succeed no matter what ports are opened on the ISA Server firewall.
Calls from station B to station A succeed as long as station A is using the proxy client. When station A creates the call, the address used as the remote address is that of its SIP server, which is local. The address received back is also local. When this is added to a session invitation to station B, B cannot use this internal address to contact station A—as a result these calls fail. When station B initiates the call, B's address from the SDP data in the invitation can be used as in deployment 1. This is illustrated in Figure 8.
This article discusses several scenarios describing what you need to use all Windows Messenger features and provides possible solutions to identified issues.
When NAT or firewall devices are added in the communication path for Windows Messenger, various difficulties might arise. Nearly all of these issues are addressed through the use of UPnP-enabled Internet gateway devices. Many vendors are already building this capability into their devices and some are even considering back-porting the capability to older, upgradeable devices.
Glossary of Acronyms Used
ALG – Application Layer Gateway
AS – Application Sharing
AV – Audio and Video
FT – File Transfer
ICF – Internet Connection Firewall
ICS – Internet Connection Sharing
IM – Instant Messaging
ISA – Internet Security and Acceleration
ISP – Internet Service Provider
NAT – Network Address Translation
RDP – Remote Desktop Protocol
RTC – Real Time Communication
RTP – Real-time Transport Protocol
SDP – Session Description Protocol
SIP – Session Initiation Protocol
SSL – Secure Sockets Layer
TCP – Transmission Control Protocol
UDP – User Datagram Protocol
UPnP – Universal Plug and Play
WB – Whiteboard (Sharing)
For more information about Windows Messenger, its underlying protocol and standards, and how it functions with UPnP, NAT, and firewall devices, visit the pages:
For the latest information on Windows XP, check out the Microsoft Windows XP website.