Windows Messenger opens the doors to all kinds of real-time electronic communication: instant messaging, video conferencing, voice conversation, remote assistance, and application sharing and file transfer. Additional features, such as making calls to a regular phone and sending instant messages to pagers are also possible with Windows Messenger. These types of real-time electronic communication stand ready to revolutionize the way that your company does business.

If you’re thinking about employing Windows Messenger as a communication tool on your network, you need to be aware of how it will interact with your network’s first line of defense—the firewall—as well as Network Address Translation (NAT) components. In some cases, all of Windows Messenger’s components will work just fine with your firewall and NAT. In other cases, certain components will be limited or not work at all. The chances of you falling into the former are pretty slim. You’ll need to be prepared to perform some additional configuration to get all of Windows Messenger’s components to work properly, and to do so, you really need to have an understanding of the underlying technology.

I’ll explore the ins and outs of how Windows Messenger works with a firewall and NAT component. I’ll start at the bottom and work up as I examine each piece in the puzzle. I’ll then explain how all these pieces must function together in order for all of Windows Messenger’s components to work.

Windows Messenger’s components
Let’s take a look at each one of Windows Messenger’s components and focus on the types of problems that can arise when you try to employ these components behind a firewall and NAT.

Instant messaging and Presence
Probably the biggest uses for Windows Messenger are instant messaging (IM) and Presence. Of course, IM provides users the ability to send and receive typewritten messages in real time. Presence is a component of IM that allows you to see when your friends are online.

IM and Presence don’t have any real problems working through a firewall or NAT because both IM and Presence can use the TCP connection and are actually server-mediated sessions. This is important for two reasons:

  1. ·        The information transferred in IM sessions is text-based. It can ride along on the TCP connection without any special considerations.
  2. ·        Since the communications are server-mediated sessions, messages between the two parties are actually sent to the server, which then forwards them to the recipient—there’s no direct connection between the two parties.

Since the IM messages are text-based and use the TCP connection, they can sail right through your firewall just like the information that makes up the pages that your browser renders. In fact, IM text is packaged as hypertext and uses the Hypertext Transfer Protocol (HTTP). Furthermore, the packets that make up the underlying IM communication contain the proper credentials. Let’s take a closer look at this last point, because the success of IM will help you understand the failure of some of the other Windows Messenger components’ communication operations.

As a packet to be sent from an IM client to the server is created, the IM server’s IP address and the correct port number are added to the packet. The client’s private IP address is also added to the packet along with the port number. When the packet hits the NAT, the private IP address is replaced by the public IP address. Then, when the packet hits the firewall, both the destination and source credentials (IP addresses and port numbers) appear to be in proper order, and the firewall allows the packet to pass. Packets returning from the IM server are likewise in proper order and allowed to pass through the firewall.

Video conferencing and voice conversation
Video conferencing and voice conversation are probably the most exciting features that Windows Messenger has to offer. They’re also the most troublesome when it comes to working with a firewall and NAT.

To begin with, video conferencing and voice conversation require both server-mediated and peer-to-peer sessions. The initial communication and session setup is conducted through Windows Messenger via server mediation. Then, once the connection parameters are set up and agreed on, a peer-to-peer session between the two systems is established and the real communication begins using the Real-time Transport Protocol (RTP) over the User Datagram Protocol (UDP) and the agreed-on port number.

Again, for this to work, the data packets need to have the proper credentials in order to adhere to the rules set forth by both the firewall and the NAT. During the initial setup via the server-mediated sessions, the packets do have the proper credentials. However, once the session switches over to a peer-to-peer connection, it can easily break down.

The first breakdown occurs if the port number isn’t opened by the firewall. Windows Messenger is designed to use a dynamic port selection scheme when selecting a port to use for an audio-video (AV) stream. The reason that Windows Messenger is designed to do this is so that the AV session can work regardless of any other application running on the system and using other ports. The port numbers that UDP can use for an AV stream range from 5004 to 65535.

The second breakdown occurs if, in the transition from server-mediated session to a peer-to-peer one, the NAT is unable to do its job and the source IP address isn’t translated from private to public. When this happens, the private IP address doesn’t pass muster with the firewall.

Remote Assistance
Windows XP’s Remote Assistance is another unique feature that is accessible within Windows Messenger. Remote Assistance uses the Remote Desktop Protocol (RDP), which also rides along on top of a TCP connection. To do its job, Remote Assistance needs access to port 3389, as well as a valid IP address to use for a peer-to-peer direct connection. If the port isn’t open or the IP address doesn’t get translated, the connection will fail.

Application sharing
If you want to use Windows Messenger’s application sharing and whiteboard features, the TCP connection needs access to port 1503. In addition, the application sharing and whiteboard features need a valid IP address to use for a peer-to-peer direct connection. If the port isn’t open or the IP address doesn’t get translated, the connection will fail.

File transfer
For the file transfer procedure to work, the TCP connection needs access to ports 6891 to 6900, as well as a valid IP address. If none of these ports are open or the IP address doesn’t get translated, the connection will fail.

How Universal Plug and Play comes into play
At this point, you have a good idea of Windows Messenger’s capabilities, what it needs to do its job, and the problems that you can encounter with firewalls and NAT components. Now, let’s explore a relatively new advancement in firewall and NAT technology—Universal Plug and Play (UPnP).

Do you remember setting jumpers? If you do, you already can appreciate how Plug and Play (PnP) changed the way that you configure almost all of the cards in a workstation. For those of you who don’t remember, in the old days, if you needed to change the COM port on a modem, you had to open the PC, take the modem out, and then use tweezers to move the tiny jumper block from one set of pins to another. You can imagine all the possible trials and tribulations of performing such an operation and then trying to get the software to cooperate.

Thankfully, those days are gone. The PnP technology allows you to make such changes right from within Windows—you never have to touch the card. The key to success here is the fact that all new computers come with a PnP BIOS and almost all card manufacturers now design their products to be PnP-compliant, which gives them the intelligence to communicate and accept instructions from Windows, which allows them to be instantly configured.

With this in mind, you can probably see where UPnP comes into play with firewall and NAT technology. Basically, you can think of UPnP as a network version of PnP.

Until recently, firewalls and NAT components were just “set it and forget it” devices. You installed the firewall and NAT components on a network to protect and share IP addresses, respectively, and that was that. They just sat out on the network and did their jobs without any direct interaction with any of the computers. In other words, they weren’t UPnP-compliant.

Then Windows Messenger came on to the scene with all of its demands for access to previously blocked ports and special access to NAT-provided public IP addresses for peer-to-peer connections over the Internet. For all of Windows Messenger’s components to work seamlessly with firewall and NAT, Windows Messenger needs to communicate its needs to these devices and the devices need to be able to respond and configure themselves accordingly. That means that the firewall and NAT must be UPnP-compliant.

Right out of the box, Windows XP and Windows Messenger are capable of communicating with UPnP firewall and NAT components, allowing seamless access to such Windows Messenger components as video conferencing. The UPnP capability can be added to Windows 98, Windows 98 SE, and Windows Me by running the Network Setup Wizard that comes with Windows XP, creating the network setup floppy disk, and running it on those systems.

Without UPnP
Without UPnP firewall and NAT components, you can still take advantage of Windows Messenger’s communication components, but you’ll have to do some extra work. As I mentioned, Windows Messenger’s IM and Presence components work seamlessly regardless of the firewall and NAT components, just like Web browsing and e-mail. However, to take advantage of some of the other communication components, you’ll need to delve into the firewall and NAT configuration software and open ports and reroute NAT connections using such features as port forwarding, which forwards incoming requests for specific ports to specific internal IP addresses, or Demilitarized Zone (DMZ) settings, which allow you to place a certain IP address outside the firewall where it can directly interact with other computers on the Internet in a peer-to-peer configuration.

Of course, such changes reduce security and make the network vulnerable to attack from hackers. If these changes are switched on and off when needed, the risk is minimal. However, the manual intervention needed each and every time access is required can become very time consuming and frustrating.

Upgrade your firewall and NAT components

While most of the new firewall and NAT components are UPnP-compliant, many of the older products aren’t. The good news is that most of the companies that make firewall and NAT components have, or are planning to release firmware or software upgrades to their products to make them UPnP-compliant.

Windows XP’s built-in solution
If you’re running Windows XP and are configuring a small office network, you may want to bypass hardware-based firewall and NAT products and use the operating system’s built-in solutions—Internet Connection Sharing (ICS) and Internet Connection Firewall (ICF)—which are, of course, fully UPnP-compliant services. All of Windows Messenger’s communication components should work seamlessly.

ICS, which was introduced in Windows 98 SE and appeared in Windows 2000 and Windows Me, performs the job of the NAT, translating the private internal IP addresses to the public IP address. Of course, ICF, which is a new feature only available in Windows XP, provides the firewall protection. In this scenario, the Windows XP computer is connected to the Internet and then uses ICS to provide access to the Internet for all the other computers on the network. ICF is then configured to protect the ports from unauthorized access.

A cascading problem

If you’re using UPnP firewall and NAT components on both ends and still are experiencing problems getting all of Windows Messenger’s communication components to work seamlessly, you may want to investigate the possibility of a cascading problem. Keep in mind that this kind of problem isn’t common but will be worth taking a look at if you’re positive that the firewall and NAT configurations on both ends should be working.

In this type of situation, another firewall or NAT could exist between your network and the one you’re trying to contact. And, of course, the additional firewall or NAT will be in use by the Internet service provider (ISP). In this case, you’ll need to contact your ISP to explore the problem and solutions in greater detail.

Further research
If you want to delve deeper into the world of Windows Messenger and UPnP firewall and NAT components, investigate some of these additional resources: