NT Gatekeeper: RPC and Firewall Configuration

My company acquired portal software that the IT department will use to provide Internet services to the company's customers. The portal software is a distributed client-server application rooted in COM+. I'm responsible for the firewall and security-zone setup. One fundamental rule of my security policy is to put all business-logic and database servers in the trusted security zone. My security-zone setup consists of a demilitarized zone (DMZ) that I've separated from both the Internet and the internal network (the trusted security zone) by using two firewalls. How can I set up Distributed COM (DCOM) and remote procedure call (RPC) connectivity between a Web server in the DMZ and a business-logic server in the trusted security zone without punching too many holes in the firewall that separates the DMZ from the trusted security zone?

Before I go into setup details, let me first explain the role of the different protocols used in your portal-server setup. DCOM is the wire protocol that defines how and which messages are exchanged between COM+ client and server components. DCOM uses Microsoft's RPC protocol. RPCs let a program call on the services that another program offers. The other program can reside on the same machine as the caller program or on another machine. For example, a Microsoft Outlook client calls on RPCs to access messaging services on a remote Microsoft Exchange Server machine. If the Outlook client and the Exchange server are collocated, they communicate by using "local" RPCs (also known as local procedure calls—LPCs).

A key problem in configuring firewalls to let through RPC-protocol messages is RPC's use of dynamic inbound ports. With the exception of the RPC Portmapper service, which uses a fixed port (135), all other RPC-based services use varying ports in the range 1024 to 65,535. In other words, if you want to let RPCs through your firewall, you have to punch gigantic holes in it. For a short introduction to the way in which RPC handles service ports, see the Web-exclusive sidebar "RPC Dynamic Port Allocation."

To resolve this problem, Microsoft provides two solutions: a way to restrict the port range that RPC's dynamic port allocation uses and a special protocol called Tunneling TCP to transport DCOM across TCP. To restrict the range of ports that RPC uses, add the values in Table 1, page 12, to your RPC server's HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpcInternet registry subkey. You can also set these values from the Windows GUI by following these steps:

In most cases, just configuring the port range values on the RPC server side isn't sufficient. You might also need to configure the DCOM ports on the RPC client side because DCOM uses a callback mechanism that requires a separate connection between the server and the client. This callback mechanism can't reuse the existing client-server connection.

Another solution for letting DCOM and RPC through your firewall without punching too many holes is to use the Tunneling TCP protocol. Microsoft introduced this protocol in Windows NT 4.0 Service Pack 4 (SP4). The Tunneling TCP protocol uses an HTTP handshake (based on the HTTP-CONNECT method) that lets DCOM client-server connections pass through firewalls at the beginning of the DCOM connection. After the initial handshake, the DCOM connection uses a fixed TCP port. Because the DCOM connection uses HTTP, Tunneling TCP requires a Microsoft IIS Web server on which a special RPC proxy service is installed. (This RPC proxy is available in SP4 and all later service packs.) For details about how Tunneling TCP works and how to set it up, see the Microsoft article "COM Internet Services" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/cis.asp).

In the next generation of the Microsoft component framework—the .NET Framework—Microsoft resolves the problems around RPC by introducing a new protocol called the Simple Object Access Protocol. SOAP provides a way to encode RPCs in XML-formatted messages and transport them by using the HTTP protocol.