Jacob Lundberg
CS 312 - Paper
Exchange through a Linux IP Masquerading firewall
Summary: "What is this?"
Sometimes a company will decide that they want to run Exchange as their e-mail server. In the case where this happens and it is necessary to communicate with another Exchange server over the Internet, there may well be a firewall involved. This introduces several problems for Exchange, especially if the firewall is one that hides the company's internal IP addresses from the outside world. Linux using IP-Masquerading firewalling is an example of this. However, it is possible to do. This document is a discussion of how to do it and why to do it this way.
Background: "What's the problem again?"
Exchange servers like to communicate with RPC (remote procedure calls). In fact, this is necessary for Directory Replication to occur. In an Exchange install right out of the box, Exchange uses the portmapper to dynamically allocate several ports for its RPC communication each time a connection to another Exchange server is initiated. This poses a problem for communication through a firewall because the firewall's administrator must open ports through to the Exchange server in order for it to communicate successfully. Thus in an out-of-box install, all ports would have to be opened in order to make sure that whatever port the portmapper chose would be open each time. One solution that immediately presents itself is to place the Exchange server in a De-Militarized Zone, or outside of the internal firewall but inside the external firewall. However, traffic from the Exchange server must now pass through to the inside of the firewall in order for clients to read their e-mail. This means that at least one port must be opened to all internal hosts. So if the Exchange server is compromised, internal hosts become potential targets. Also, this increases the Exchange server's exposure to the Internet. So a solution that leaves the Exchange server behind the firewall is desirous.
Solution: "How can we do it?"
In order to place the Exchange server behind the firewall, its RPC ports must be stabilized. Fortunately, there is a (very poorly documented) way to do this. By setting several values in the registry of the NT server running Exchange, Exchange can be made to select specific ports on startup. The ports chosen and registry values set must be well documented so they can be duplicated in the event of a crash, since restoring the old registry may not be feasible. The registry values are as follows:
All values are REG_DWORD types, under HKEY_LOCAL_MACHINE.
Under System\CurrentControlSet\Services\MSExchangeDS\Parameters,
add "TCP/IP port" equal to a _hexadecimal_ value.
For decimal 10001, set it to 2711.
Under System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem,
add "TCP/IP port" equal to a hex value.
For decimal 10002, set it to 2712.
Under System\CurrentControlSet\Services\MSExchangeMTA\Parameters,
add "TCP/IP port for RPC listens", equal to a hex value.
For decimal 10003, set it to 2713.
The portmapper itself will use decimal 135 always by default.
Then these specific ports are opened through the firewall for the remote Exchange server. Using Linux's new kernel firewalling code, these ports can be limited to traffic from a specific host, over a specific protocol, and to a specific host and port inside the firewall. The ipchains utility is used for this. This document specifically considers the case of a Linux firewall that is providing IP-Masquerading for the internal hosts. In this case, the firewall will need to port-forward or mark-forward packets from the remote Exchange server to the local one. Mark-forwarding is a good choice because it reduces overhead for the firewall. An example of a masquerading firewall setup that would correspond to the above Exchange setup using 206.58.127.43 as the firewall's external IP, 159.121.14.99 as the external Exchange server, and 10.10.10.2 as the internal Exchange server's IP might be:
/sbin/ipchains -F
/sbin/ipchains -P input DENY
/sbin/ipchains -A input -p tcp -d 206.58.127.43/32 23 -j DENY
/sbin/ipchains -A input -p tcp -y -s 159.121.14.99/32 -d 206.58.127.43/32 netbios-ns -m 1
/sbin/ipchains -A input -p tcp -y -s 159.121.14.99/32 -d 206.58.127.43/32 netbios-ssn -m 1
/sbin/ipchains -A input -p tcp -y -s 159.121.14.99/32 -d 206.58.127.43/32 netbios-dgm -m 1
/sbin/ipchains -A input -p tcp -y -s 159.121.14.99/32 -d 206.58.127.43/32 10001:10003 -m 1
/sbin/ipchains -A input -p tcp -y -s 159.121.14.99/32 -d 206.58.127.43/32 135 -m 1
/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A input -i eth0 -s 10.10.10.0/24 -j ACCEPT
/sbin/ipchains -A input -i ppp0 -s ! 10.10.10.0/24 -d 206.58.127.43/32 -j ACCEPT
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 10.10.10.0/24 -j MASQ
/sbin/ipchains -P output DENY
/sbin/ipchains -A output -i lo -j ACCEPT
/sbin/ipchains -A output -i eth0 -d 10.10.10.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth1 -s 206.58.127.43/32 -d ! 10.10.10.0/24 -j ACCEPT
/usr/sbin/ipmasqadm mfw -A -m 1 -r 10.10.10.2 -p 100
This requires the ipchains and ipmasqadm tools. Port 135 is needed for the portmappers on the Exchange servers to communicate; this assumes that the remote Exchange server will have no need to talk to the portmapper on the firewall box, which is probably not available to the Internet anyway.
Future: "What happens next?"
In the 2.3 Linux kernel series, the kernel firewalling code has been rewritten again. This will probably mean that the ipchains utility will be extensively rewritten or replaced in a year or two. As for Exchange, it is difficult to speculate effectively on future changes, but it is unlikely that Exchange will stop needing RPC any time soon, so there will continue to be some need for this information. An excellent task for the future is to write a mini-HOWTO for the Linux Documentation Project on this topic.
References: "Where's that ipmasqadm package at, huh?"
ipchains - HOWTOs on linuxdoc.org
http://metalab.unc.edu/pub/Linux/docs/HOWTO/IP-Masquerade-HOWTO
http://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO
ipmasqadm - tool and FAQ on kernelnotes.org
http://juanjox.kernelnotes.org/
http://juanjox.kernelnotes.org/ipmasqadm-FAQ.txt
Exchange - deep in the Exchange off-white papers
http://support.microsoft.com/support/kb/articles/Q176/4/66.ASP
http://support.microsoft.com/support/kb/articles/Q161/9/31.ASP
http://support.microsoft.com/support/kb/articles/Q180/7/95.ASP
http://support.microsoft.com/support/kb/articles/Q155/8/31.ASP