Deploying ISA Server 2004

Welcome back to the series on ISA Server 2004. So far we’ve talked about what ISA server is and does, and its functions and editions. This article will take it one step further by discussing the many different ways you can use ISA server in your network, no matter how large or small.

ISA Server 2004 can be deployed in a number of different configurations to suite your organization’s needs. Since ISA server is well suited for small, medium, and large businesses, a wide variety of deployment scenarios are possible. There are three basic deployment configurations we will discuss, and then talk about some variations on these.

The first scenario is as an internet edge firewall, probably the most common scenario. The ISA Server protects an internal network from an external one, such as the Internet. One network interface is attached to the Internet, or other untrusted network, and the internal network is attached to the second interface. There may or may not be a perimeter network between the Internet-facing ISA server and the internal network, depending upon the size of the network and the needs of the organization. The ISA server may allow internal servers to be published, such as a web server, and it may even operate as a VPN server. In any case, the ISA server serves as the only entry and exit point into the internal network from the outside world, and controls all inbound and outbound network traffic.
A second method is to deploy the ISA Server as a back-end firewall. In this case, the ISA server is one of two firewalls deployed in a demilitarized zone (DMZ) or perimeter network configuration. The front-end or Internet-facing firewall serves as initial entry point into the network. This machine may or may not be an ISA server. This firewall offers some protection for the internal network and serves as the primary protection for servers deployed inside the DMZ. The ISA server acting as the back-end firewall, on the other hand, primarily protects internal assets and allows publishing of resources outside the internal network. For example, a web server in the DMZ may require data from an SQL server that resides on the internal network. The back-end server would allow access to the SQL server from the web server inside the DMZ only, and not from any other external host. Then the web server would provide requested data to an Internet host through the front-end firewall.
Yet a third scenario would be to use an ISA server as a branch office firewall and/or VPN server. In this case, the ISA server would serve as a single entry point into a smaller, geographically separated branch office network, usually connected to the Internet with a WAN connection, and connect to another ISA server at the main office, in a site-to-site VPN configuration.

Keep in mind that when factoring in additional roles for your firewall, such as proxy or caching server, VPN server, or a remote access server, this can add variations to the complexity of the basic scenarios mentioned above. You may choose to have separate ISA servers host these roles, or combine them onto one server. Additionally, having arrays configured in each of these scenarios can both add to your deployment options and the overall complexity of the deployment, as an ISA server may also function solely as a configuration storage server for an array. The bottom line to remember here is that ISA Server 2004 is quite versatile; it can be deployed to fit the unique needs of any size organization.

With that, we’ll close out this installment. In our next article, we’ll discuss an often-overlooked, but extremely critical part of getting ISA Server 2004 up and running – the planning step. See you then!