ISA Server 2000 Exchange 2000/2003 Deployment Kit Network Topologies
By Thomas W. Shinder, M.D.
The ISA Server 2000 Exchange 2000/2003 Deployment Kit was released just a couple of weeks ago and has already had over 15,000 downloads. This indicates the information contained in the ISA Server 2000 Exchange 2000/2003 Deployment Kit fills an important gap for the ISAServer.org community. We’ve also received a lot of positive information on the kit and your positive comments about the work are very warmly appreciated!
One thing a number of ISAServer.org members wrote in to say is they would like to see some examples of network topologies used in the ISA Server 2000 Exchange 2000/2003 Deployment Kit examples. These folks felt that adding some graphic representations of these networking topologies would help a lot in terms of defining relationships between the important players in a secure ISA/Exchange remote access solution.
Keep in mind when reviewing procedures in the ISA Server 2000 Exchange 2000/2003 Deployment Kit and the network topologies examples in this article is that we have chosen to provide examples of relatively simple configurations. The reason for doing it this way is to communicate how the basic components work, how they work together, and how to test a successful working configuration.
The most frustrating issue ISAServer.org members mention regarding current documentation is that its written for complex environments using multiple servers. The networking topologies become so complex that the core information is lost in a forest of multiple firewalls, VLAN configurations and back end servers. The ISA Server 2000 Exchange 2000/2003 Deployment Kit topologies focus first on how to get things working. Once you understand how to get secure remote access to an Exchange Server on the internal network using ISA Server, you can move to the next step of creating and configuring more complex topologies.
In this article we’ll go over the following scenarios and network topology diagrams:
Note:
For detailed, step by step instructions on carrying out each of the scenarios described in this article, please refer to the ISA Server 2000 Exchange 2000/2003 Deployment Kit.
Authenticating SMTP Relay on the Internal Network
SMTP relays are used to protect your Exchange Sever from ever needing to directly contact an untrusted SMTP client or server. The SMTP relay can be make responsible for MX name resolution and receive inbound mail, as well as send outbound mail. All organizations that host there own Internet mail services should use an SMTP relay to protect their Exchange Server from external attack.
Note:
For details information on the various types of SMTP relays, please check out Part 1, Part 2 and Part 3 of my SMTP Relay article series.
An SMTP relay can accept both unauthenticated and non-authenticated connections. Non-authenticated connections are used to accept inbound mail to domains under your administrative control. You must provide a non-authenticating SMTP relay to accept inbound mail as external SMTP servers are not able to provide credentials.
An authenticating SMTP relay is helpful when you have remote users who do not have access to an SMTP server. These users are typically POP3/SMTP users located at remote sites where they are not directly connected to an ISP. They might be connected to a hotel broadband network, or home users who you do not want sending sensitive corporate mail via non-secure channels. The authenticating SMTP relay can also be configured to require a secure SSL/TLS link so that both the credentials and the data are encrypted.
The figure below shows the relationships between the participating clients and servers in this type of configuration.
Authenticating SMTP Relay on the ISA Server Firewall
Many organizations are financially strapped and do not have access to a machine to put between the ISA Server firewall and the Exchange Server on the internal network. This is a typical small business scenario where the Exchange Server is also located on the domain controller. In situations like this you can put the authenticating SMTP relay on the ISA Server firewall computer itself.
If the ISA Server firewall computer is a member of the internal network domain, you can allow your users to authenticate with the SMTP relay located on the firewall. This allows users to relay mail to any mail recipient in the world. Non-authenticated connections are allowed to relay mail only to domains under your administrative control.
There are two advantages to this configuration:
The disadvantage of running this configuration is that the SMTP Message Screener can be processor intensive. If you process a large volume of SMTP messages, both inbound and outbound, you may find firewall performance is degraded. You can solve this problem, to a certain extent, by using a more powerful processor or multiple processors in the ISA firewall machine.
The figure below shows the relationships between the clients and servers in this scenario:
Secure Exchange POP3/IMAP4/SMTP Publishing
The ISA Server firewall can publish Exchange Server services in both a secure and non-secure fashion. Remote users can access the Exchange POP3, IMAP4 and SMTP services using an open non-secured connection or an SSL/TLS secured link. The secure link protects both the user credentials and data.
POP3 and IMAP4 access is useful for organizations that prefer to not use OWA for remote access to Exchange mail. Non-secure connections pass both credentials and data in unencrypted form and can potentially expose corporate data to intruders. You can completely mitigate this concern by requiring a secure SSL/TLS POP3 or IMAP4 connection to the Exchange Server.
Allowing secure SMTP access to the Exchange Server is useful for users who do not have access to an SMTP server at their remote location. You can require authentication and SSL/TLS on the connection. This allows users to relay mail to mail domains that are not under your administrative control.
However, you should do whatever you can to avoid publishing a non-authenticating SMTP server on the Exchange Server itself. You should always use an SMTP relay. Even if you don’t have another machine to use for a dedicated SMTP relay, you can always use the ISA Server firewall as a non-authenticating relay for inbound mail to domains under your administrative control. There is very little processing overhead to a plain non-authenticating SMTP relay, so there is no excuse to ever allow unauthenticated connections to the Exchange Server.
The figure below shows the relationships between the clients and servers in this scenario.
Secure and Non-secure POP3/IMAP4/SMTP Publishing in a Front-end/Back-end Exchange Configuration
A front-end/back-end Exchange configuration allows remote users to connect to a front end Exchange Server that does not contain a message store. The front-end/back-end configuration is a great way to provide load balancing and unified name space for your Exchange Server organization. ISA Server firewalls provide the ideal way to provide secure remote access to the front-end servers.
The POP3/IMAP4/SMTP client can be configured to connect using either a secure or non-secure connection to the front-end Exchange Server. Secure connections are protected by SSL/TLS encryption that protects both the user credentials and the data. The link between the front-end and the back-end Exchange Servers cannot use SSL, so an IPSec transport mode connection is used between the front-end and back-end Exchange Servers. This insures that the link is secure from end to end.
The ISA Server firewall also protects these Exchange Server services from attack using its smart layer 7 aware applications filters. Unlike traditional firewalls that are based on simple packet filtering mechanisms, the ISA Server firewall exposes the SMTP and POP3 connections to SMTP filter, SMTP Message Screen and POP3 filters. Good packets are passed to the front-end Exchange Server and bad packets go to the place were all bad packets go.
J .
Secure Outlook Web Access Publishing
If there is one reason to use an ISA Server firewall over any other type of firewall, its the ability to provide a highly secure OWA connection between the Internet Explorer client at a remote location and the Exchange Server on the internal network. OWA publishing provides a level of security and availability for OWA access that no other firewall can provide. Period.
ISA Server firewalls can perform SSL to SSL bridging. A secure SSL link is created between the Internet Explorer client on the Internet and the external interface of the ISA Server firewall. Then the ISA Server firewall decrypts the packets and inspects them. If the connection attempt is legitimate, then the packets continue their journey. If the connection attempt is illegitimate, then they are dropped by the firewall.
Packets passing inspection are forwarded to the OWA server on the internal network via a second SSL link. This link exists between the internal interface of the ISA Server firewall and the OWA server on the internal network. The return path between the OWA site and the remote client is the same at the inbound path, except in reverse.
SSL to SSL bridging works without requiring any third party software. Another valuable feature that does not require any third party software is delegation of basic credentials. The ISA Server firewall can be configured to pre-authenticate the remote user before the connection attempt is forwarded to the OWA site on the internal network. This prevents unauthenticated connections from ever arriving at the OWA server and any exploits that might be carried out by unauthenticated connections.
The figure below shows the relationships between the relevant clients and servers.
Outlook Web Access Publishing in a Front-End/Back-End Exchange Server Configuration
OWA publishing works almost the same when you have a front-end/back-end Exchange configuration. The front-end Exchange Server is published using a secure Web Publishing Rule that insures a secure SSL to SSL bridging link between the remote Internet Explorer OWA client and the front-end Exchange Server OWA site on the internal network. The methods are the same as those used when you publish an OWA site that is not part of a front-end/back-end configuration.
The difference with the front-end/back-end configuration is that you can not configure the front-end OWA site to use SSL to secure the link between the front-end and back-end. However, you can use IPSec tunnel mode to protect all the data moving between the front-end and back-end. By using IPSec transport mode between the front-end and back-end server, you insure that the communications are secure from end to end. There are no non-secure links anywhere in the chain.
The figure below shows the relationships between the clients and severs in this scenario.
Secure Outlook Web Access Publishing with a Unihomed Web Proxy (caching-only) ISA Server Firewall
Many organizations have a firewall solution in place but still want to take advantage of the unique level of protection only ISA Server firewalls can provide. You can leverage ISA Server’s SSL to SSL bridging, pre-authentication and deep content inspection of packets within the SSL stream by installing ISA Server in Web Proxy (caching-only) mode and install only a single NIC on the ISA Server machine.
The firewall in front of the ISA Server forwards all inbound OWA connection requests for HTTP and SSL to the ISA Server. The ISA Server then uses SSL to SSL bridging, pre-authentication deep HTTP content inspection within the SSL stream and forwards the request to the Exchange Server behind the internal firewall. The internal firewall only needs to be able to forward HTTP and SSL to the OWA site on the internal network.
The figure below shows the relationships between the clients and servers in this scenario.
Summary
The ISA Server 2000 Exchange 2000/2003 Deployment Kit provides all the information you need to allow eminently secure remote access connections to Exchange Server services on the internal network. This article provides some examples of the network topologies used in the detailed step by step articles contained in the kit.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=6;t=002111 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!
