About Outlook/Exchange through the Firebox [WFS]
Posted by Samuel Turi on 03 May 2011 01:09 PM

About Outlook/Exchange through the Firebox [WFS]


Basic Description

Sometimes Outlook Web Access is not an option for remote Exchange server access, or you have an Exchange server on the optional interface and clients on the trusted interface. Direct communication on specific ports is necessary for the Exchange client to communicate with the server. Exchange has two modes in which to do this. The first is dynamic negotiation with DCE-RPC (the Firebox is capable of following the dynamic negotiation that happens with DCE-RPC), the second is manually setting the ports on which Exchange will communicate with the server. Because of the security considerations and the number of potentially vulnerable services that use DCE-RPC, it is usually not a good idea to use it. We will discuss both of these methods (DCE-RPC and static-mapped) here.

Allowing this service inbound, static-mapped mode

This is the preferred method, and should be used when the Exchange server and the clients are on different networks (trusted and optional or optional and Internet or trusted and Internet). We recommend the use of WatchGuard Authentication with these services to prevent possible exploitation of vulnerable Exchange servers, especially if the clients are going to be on the Internet.

First, configure your Exchange server to Force Static Mapping of Sockets. See Microsoft article #Q155831 (http://support.microsoft.com/support/kb/articles/q155/8/31.asp). Thoroughly go through the instructions provided there. Remember the two port numbers that you assigned.

Verify the ports by launching an Outlook client and connecting to the Exchange server from behind the Firebox on the same network that the Exchange server resides.

After a successful Exchange client to Exchange server communication, open an MS-DOS Window and type netstat -n. Press Enter. The resultant output displays protocol statistics and current TCP/IP network connections. The following is a sample output:


TCP 192.168.36.208:1051 192.168.36.44:1059 ESTABLISHED
TCP 192.168.36.208:1055 192.168.36.44:1086 ESTABLISHED
TCP 192.168.36.208:1060 192.168.36.44:1059 ESTABLISHED
TCP 192.168.36.208:1064 192.168.36.44:1086 ESTABLISHED
TCP 192.168.36.208:1120 0.0.0.0:0 LISTENING

You should see the same two ports that you have previously assigned to the Exchange server. In the example above, the Exchange server IP address is 192.168.36.44 is using TCP ports 1086 and 1059. You must add custom service rules for these ports to the Services arena in Policy Manager.

Add three custom service rules as follows:

Name Protocol Client Port Port

Exchange1

TCP

client

1086

Exchange2

TCP

client

1059

Exchange3

TCP

client

135

Service properties for these three service rules should be set as follows:

  • Incoming -- Enabled and Allowed from IP addresses of the Exchange clients on the Internet to IP address of Exchange server behind the Firebox
  • Outgoing -- Enabled and Allowed from the IP address of the Exchange server behind the Firebox to the IP addresses of the Exchange clients on the Internet

Allowing this service inbound, DCE-RPC mode

If you must use DCE-RPC mode, simply add a DCE-RPC proxy service and configure the service rules to like this:

  • Incoming -- Enabled and Allowed from IP addresses of the Exchange clients on the Internet to IP address of Exchange server behind the Firebox
  • Outgoing -- Enabled and Allowed from the IP address of the Exchange server behind the Firebox to the IP addresses of the Exchange clients on the Internet

Note:  Please be aware that the DCE-RPC service does not properly follow the dynamic port negotiation in all cases. In some configurations, the only way to allow this service inbound will be in static-mapped mode.

Note:  Never allow incoming from 'Any' to the Exchange Server in the DCE_RPC filter rule or the custom filter rules defined above. Doing so could compromise your Exchange Server and internal network. If you are unable to identify the IP addresses of clients outside your Firebox who require Exchange Server access, then use an authentication method like wg_authentication or set the users up through a VPN tunnel. VPNs are the preferred method in any case.

Allowing this service outbound

If you have Exchange clients behind your Firebox that are trying to connect to an Exchange server outside of your network, use either one of the methods mentioned above, of configure an Outgoing TCP service. With the Outgoing service, the Exchange server will not be able to communicate with the clients, only the clients will be able to communicate with the server. This works fine, but the server will not be able to push email notifications to the clients. The clients will have to manually access some information on the Exchange server in order to receive new mail notifications.

Denying this service inbound

By default, this service will be denied inbound. No configuration change should be necessary.

Denying this service outbound

By default, this service will be allowed outbound with the Outgoing service. You must either remove the Outgoing service or add a DCE-RPC service and set the outgoing properties to Enabled and Denied.

Using this service with NAT

Incoming static-NAT will work fine in static-mapped mode. Outgoing-NAT will also work fine with static-mapped mode. There are some issues with using the DCE-RPC proxy filter with either type of negotiation.

(0 vote(s))
Helpful
Not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below (we use this to prevent automated submissions).