Export (0) Print
Expand All

Windows Messenger 5.0 in Windows XP: Working With Firewalls and Network Address Translation Devices

Published: October 01, 2001 | Updated: September 04, 2003
By Tom Fout

Microsoft Corporation

Abstract

This article discusses several scenarios describing what will be needed to use all Windows Messenger 5.0 features and provides possible solutions to identified issues.

Using Microsoft® 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 new 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 NATs.

On This Page

Acknowledgements
Introduction
NAT and Firewall Issues
NAT and Windows Messenger
Firewalls and Windows Messenger
Windows Messenger Configurations: What Works and What Doesn’t
Solutions
Audio and Video with Microsoft Internet Security and Acceleration (ISA) Server
Summary
Glossary of Acronyms Used
Related Links

Acknowledgements

Ann Demirtjis, Lead Program Manager, Microsoft Corporation

Imad Yanni, Product Manager, Microsoft Corporation

Michael Kessler, Technical Editor, Microsoft Corporation

Introduction

This article discusses several scenarios describing what will be needed to use all Windows Messenger features and provides possible solutions to identified issues.

Windows Messenger provides an exciting, new real-time communication experience that will revolutionize the way people communicate. Using Windows Messenger 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. Certain networks, such as business or residential, may also deploy firewalls and/or Network Address Translation (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 (TCP)/User Datagram Protocol (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 new Windows Messenger features work as intended. However, there are network set ups that require special configuring for all of the new 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 NATs.

NAT and Firewall Issues

This section explains the Windows Messenger features affected by NAT and Firewall issues: Instant Messaging and Presence, 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 will work seamlessly. And there are also configurations where certain capabilities are limited or will 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 will become 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 on 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

In general, there are no issues with IM and presence 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 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 may 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 may 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 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 .NET Messenger case 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 will 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 will 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 will use port 1503, which will need to be enabled to traverse any firewalls. This is not true in the case of a UPnP-enabled gateway which will map 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

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 to 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 will only be able to do one file transfer at a time.

Remote Assistance

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 FT. 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 will not 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 leverage 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, 98SE, ME). 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. 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 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 will 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 Firewalls

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.

Non-UPnP Firewalls

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 will 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.

  • FT can be enabled by opening ports 6891 to 6900 on the firewall. Remote Assistance can be enabled by opening port 3389.

Cascading Firewalls

Cascading firewalls can cause problems similar to cascading NAT devices.

Limitations of UPnP in Windows XP

In Windows XP, outgoing calls from Windows Messenger will not work when ICF is enabled on the local interface and the user does not have administrative privileges. This feature will work 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 Doesn’t

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 will 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 below.

Figure 1: Using a single UPnP-enabled NAT

Figure 1: Using a single UPnP-enabled NAT

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 below.

Figure 2: Connecting through UPnP -enabled gateways

Figure 2: Connecting through UPnP -enabled gateways

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 will recognize that they are behind the same device and that they can communicate directly as shown in Figure 3 below.

Figure 3: Two clients behind a UPnP enabled gateway

Figure 3: Two clients behind a UPnP enabled gateway

Configurations That Won’t Work

The following configurations contain barriers to Windows Messenger communications other than IM and Presence.

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 below.

Figure 4: ISP using a NAT device

Figure 4: ISP using a NAT device

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 will not allow Home “B’s” personal computer to determine its translated addresses. This is illustrated as shown in Figure 5 below

Figure 5: Using a Non-UPnP NAT

Figure 5: Using a Non-UPnP NAT

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 below.

Figure 6: Using a non- UPnP NAT

Figure 6: Using a non- UPnP NAT

Solutions

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.

NAT Devices

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 may 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 allow 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 on these products refer to this press release http://www.microsoft.com/presspass/press/2001/Jul01/07-17GatewayDevicesPR.mspx, and the vendors’ Web sites.

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

None.

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 will enable RTP based AV.

Firewall Devices

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 will be used.

Workarounds for Firewall Issues

The solution to these firewall issues is provided again by UPnP. Windows Messenger will detect UPnP- enabled firewalls and configure 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 below.

Available Firewall Solutions

The firewall provided with Windows XP—Internet Connection FirewalI—supports configuration using UPnP. Windows Messenger will detect this capability and open the appropriate ports to allow your communication to proceed. If you are using another vendor's firewall product, check the vendor-provided information to determine if UPnP will be supported, or find out how to configure the firewall to allow the ports listed to pass. See Administrator/User Action Required

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 through 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 a Microsoft 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.

Scenarios

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 will 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 below.

Figure 7: Using ISA server as a firewall and proxy

Figure 7: Using ISA server as a firewall and proxy

Deployment 2: Using ISA Server

This scenario is slightly different; calls from station A to station B will never succeed no matter what ports are opened on the ISA firewall.

Calls from station B to station A will 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 as shown in Figure 8 below.

Figure 8: Using ISA Server

Figure 8: Using ISA Server

Summary

This article discusses several scenarios describing what will be needed 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)

Related Links

For more information about Windows Messenger, its underlying protocol and standards, and how it functions with UPnP, NAT and firewall devices follow the links below:

For the latest information on Windows XP, check out our Web site at http://www.microsoft.com/windowsxp/default.asp.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft