Configuring Firewalls for Message Queuing

Applies To: Windows Server 2008, Windows Vista

This topic contains information about the specific configuration settings required to enable Message Queuing traffic to pass through firewalls as well as information about using Message Queuing with Windows Firewall.

Messaging through firewalls using the Message Queuing protocol

To send messages across firewalls using the native Message Queuing protocol, specific configuration settings are required to allow Message Queuing computers located on either side of the firewall to communicate with each other. Note that for best security practice, it is recommended that HTTP messaging be used as a solution for messaging through firewalls. These specific configuration settings include allowing Message Queuing computers located on an external network to be able to connect to Message Queuing computers on your internal network over the Internet. This is achieved by opening the following service ports on your firewall.

• With direct format names, only the TCP port needs to be opened. This provides for two-way sending, but only local reading. If you need to read from remote queues, or if you need to query Active Directory Domain Services for information regarding public queues or other Message Queuing objects, you must also open the RPC ports.

• RPC ports 2103 and 2105 can be incremented by 11 if the initial choice of an RPC port is in use when the Message Queuing service starts. Message Queuing queries RPC port 135 to discover the 2xxx-series ports.

The following firewall configurations allow you three different operating modes for remote Message Queuing computers located on external networks.

Sending messages only

For remote clients to be able to send messages, you must allow these clients access to TCP port 1801 on your firewall.

In this configuration, remote clients cannot access Active Directory Domain Services nor will messages be routed by Message Queuing servers through your internal network. This means that remote clients must be able to directly connect to the destination computer on your internal network over this port. Remote clients can then send messages using a direct format name for the destination queue.

This does not apply to dependent clients.

Sending messages with Active Directory Domain Services access

In addition to opening TCP port 1801, allowing access to RPC ports 135 and 2101 permits remote client access to Active Directory Domain Services. RPC port 135 is used for handshaking between a remote client and a Message Queuing server. Message Queuing servers also use RPC port 2101 for communicating with each other.

Assuming that multicast network packets are allowed to pass through your firewall, allowing access to UDP port 1801 also permits remote clients to send a broadcast message to automatically determine their site.

This does not apply to dependent clients.

Sending and receiving messages with Active Directory Domain Services access

In addition to opening TCP port 1801 and RPC ports 135 and 2101, allowing access to RPC ports 2103 and 2105 also permits remote clients to access queues and retrieve messages on Message Queuing computers located on your internal network.

Access to RPC ports 2103 and 2105 also allows remote dependent clients to send and receive messages using their supporting server on your network.

HTTP messaging through firewalls

The use of HTTP as a transport enables MSMQ to leverage existing firewall support, without the need for Message Queuing-specific firewall configurations, and it is recommended that HTTP be used for messaging through firewalls. For more information about HTTP messaging, see HTTP/HTTPS messages [LH].

Windows Firewall and Message Queuing

Windows Firewall monitors and restricts information that travels between your computer and a network or the Internet. Windows Firewall drops all incoming traffic that has not been sent in response to a request of the computer (solicited traffic) or specified as traffic from a program or port that has been added to the exceptions list. This behavior of Windows Firewall provides a level of protection from malicious users and programs that use unsolicited incoming traffic to attack computers.

When Windows Firewall is enabled, there is more protection for Windows computers, however, it can impair some types of communication and affect applications such as Message Queuing. To help overcome this, Windows 7 and Windows Server 2008 R2 allows administrators to define an exceptions list of applications by specifying the path to the file name of each application.

Configuring Windows Firewall for Message Queuing

By default, when you install Message Queuing or upgrade Message Queuing, Setup automatically adds Message Queuing to the exceptions list in Windows Firewall. You can remove Message Queuing from the exceptions list by running the following command:

netsh firewall delete allowedprogram program=%windir%\system32\mqsvc.exe profile=all

To add Message Queuing to the exceptions list, run the following command:

netsh firewall add allowedprogram program=%windir%\system32\mqsvc.exe name=msmq mode=enable scope=all profile=all

To view the exceptions list, run the following command:

netsh firewall show allowedprogram ENABLE

When running Message Queuing with Windows Firewall enabled, in order to view public queues on remote computers by using Active Directory Users and Computers, it might be necessary to add Remote Administration to the exceptions list.

netsh firewall set service type=remoteadmin mode=enable scope=all

When installing the HTTP Support feature for Message Queuing, setup automatically installs Internet Information Services (IIS), which is a World Wide Web Publishing service, and creates an IIS extension for Message Queuing (called MSMQ). Refer to the IIS documentation for information about configuring IIS for Windows Firewall.

For computers running Windows 7 or Windows Server 2008 R2 that are joined to a domain, you can apply a domain policy for Windows Firewall settings in Active Directory Domain Services. The domain policy will override the local Windows Firewall settings.