Using a Unihomed ISA Firewall at Branch Offices to Reduce WAN Bandwidth Usage
and Cache SSL Responses from Main Office Web Servers
By Thomas W Shinder MD, MVP
I don’t typically write about the unihomed Web proxy only configuration for the ISA firewall, but I recently encountered a situation where I needed to configure the ISA firewall for an organization with many branch offices who wanted to use the ISA firewall to save on WAN link bandwidth and cache SSL responses from corporate hosted Web sites on their intranet.
This is an interesting configuration because they didn’t want the ISA firewall to act in full firewall mode. However, they needed the firewall capability to a limited extent to protect the ISA firewall device itself and allow selective access to network services located on the unihomed ISA firewall device.
To get a better idea of what we were trying to accomplish and how we solved the problem, let’s start with a network diagram of the sample network.
In the sample network diagram below there is one main office and three branch offices. The branch offices are connected to the main office using dedicated WAN links. Each branch office network, and main office network are located on different network IDs. Packets are routed to and from each branch office to the main office and from the branch and main offices to a central Internet connection at the main office.
This geographically distributed organization had two primary goals for their ISA firewall deployment at the branch offices:
- The first goal was to cache SSL content branch office users accessed on the main office SSL Web servers. In order to accomplish this goal, Web Publishing Rules must be created at the branch office using the ISA firewall’s unique SSL to SSL bridging function. Web Publishing Rules are required because the ISA firewall cannot perform forward SSL to SSL bridging, and SSL bridging is required to access the actual content contained within the encrypted tunnel.
- The second goal was to reduce the overall bandwidth usage on the WAN links by caching as much content locally and only going over the WAN for content not cached at the local branch office ISA firewalls.
Figure 1
The figure below shows the request and response path for connections from branch office clients to Web servers on the corporate network:
The client machine at the branch office is configured as a Web proxy client. The Web proxy client sends a request to www.domain.com. Because the Web proxy client configuration is set to use Direct Access for all machines in the domain.com domain, the Web proxy client ignores the request. This requires the Web proxy client computer to do two things: resolve the name of www.domain.com itself, and then send the HTTP GET request directly to the IP address returned by the DNS server for that Web server. The DNS server on the ISA firewall returns the address of the Web listener for the Web Publishing Rule used to publish that server and the request is made to the Web listener. The Web proxy client in this scenario essentially acts like an external client making a request for a Web server on an ISA firewall Protected Network.
Note:
You might be asking yourself why did we configure domain.com for Direct Access and why did we place DNS servers on the unihomed ISA firewalls themselves. I’ll get to those details a little later in this article.
The Web Publishing Rule on the ISA firewall is configured to forward the request to the Web server on the corporate network using its FQDN on the “To” tab of the Web Publishing Rule. A hosts file entry on the ISA firewall is used to map the FQDN of the Web server on the corporate network to its actual IP address. The ISA firewall cannot be configured to use the DNS server installed on the ISA firewall device itself because the name would resolve to the IP address of the Web listeners used to publish the Web servers. The ISA firewall forwards the request to the Web server.
The Web server sees the source IP address of the request as that of the ISA firewall device and returns the response to the ISA firewall’s IP address. The ISA firewall performs SSL bridging, which enables the ISA firewall to caches cacheable responses (those with cache heading information returned by the Web server indicating that the content can be cached) in the Web proxy cache.
The ISA firewall forwards the response to the client that made the original request.
Figure 2
The request and response paths for Web requests to the Internet is seen in the figure below:
- The Web proxy client forwards Web requests directly to the ISA firewall’s Web proxy listener. The ISA firewall resolves the name on behalf of the Web proxy client. In this case, the Web proxy client machine is not responsible for name resolution and does not try to connect directly to the Web site. The ISA firewall’s network interface must be configured with a DNS server that can resolve Internet host names.
- The ISA firewall resolves the name included in the client request and forwards the connection to the Internet Web site. The ISA firewall can be configured to use Web proxy chaining to forward the request to an upstream Web proxy server, or the ISA firewall can leverage its default gateway setting to forward the request upstream to the device at the main office responsible for outbound access to the Internet. Another option is to configure the ISA firewall with a gateway address that enables it to forward the connection to the Internet from the branch office. This reduces the bandwidth usage on the WAN link, but may increase usage on the branch office’s Internet connection since the main office Web proxy server could cache content requested by all hosts on the main office network and at each branch office.
- The Web server on the Internet returns the response to the ISA firewall. The ISA firewall caches the response if it is an HTTP request. If the request was an SSL request, then the ISA firewall is unable to cache the content because it is hidden in an SSL tunnel. The ISA firewall cannot perform outbound SSL bridging at this time. For this reason, you should be very discrete about what SSL sites you allow users access to, and what users are allowed access to the SSL protocol (or any other protocol that is encrypted as it moves through the ISA firewall).
- The ISA firewall returns the response to the client that made the original request.
Figure 3
Note:
The term “outbound” bridging might seem a bit confusing or counterintuitive in this scenario, since we typically think of Access Rules enabling outbound connection and publishing rules enabling inbound connections. In the scenario presented in this article, both the Access Rules and the Web Publishing Rules are allowing “outbound” access from the branch office ISA firewall to a different location outside the branch office. It might be more accurate to say that the ISA firewall cannot perform SSL to SSL bridging for Access Rules, but it can perform SSL to SSL bridging for Web Publishing Rules. We can enable SSL to SSL bridging for Web Publishing Rules because we can predetermine the names required on the Web site certificates bound to the Web listener and we know the names of the sites to which the clients connect through the Web Publishing Rule. In contrast, Access Rules are used to allow SSL connections to any SSL Web server and we can’t determine in advance what the names of those sites would be.
In this article I’ll go into deep detail on the rationale behind the configuration decisions we made for this project. If you’re interested in how the ISA firewall’s networking model works, how the ISA firewall resolves names, how the Web proxy client Direct Access feature enables you to get fine-tuned control over how sites are accessed through the ISA firewall, how to use wildcard certs to reduce the number of Web Publishing Rules you need to create, and a lot more, then read on.
The figure below shows the sample network I created to demonstrate the principles and procedures we used to create the branch office scenario described above. The sample network lacks a router between the branch office ISA firewall and the main office ISA firewall (because I didn’t want to go through the effort of building a VM for the router). This isn’t an issue, since the solution works the same without the router. This is the actual VM network I used to test the proof of concept design for the deployed solution.
Figure 4
The sample network includes the following key components:
Main office ISA firewall
External: 192.168.1.71
DG: 192.168.1.60
Internal: 10.0.0.1
The main office ISA firewall is used to simulate the routed connection between the branch office and the main office. I created an ISA firewall Network for the 192.168.1.0/24 network ID and then created a Network Rule defining a route relationship between the main office ISA firewall’s default Internal Network and the network on which the branch office firewall is located. I could have used an RRAS router, but I had an ISA firewall VM that I could use to simulate the main office router, so I used it. I configured an Access Rule that allowed all traffic from the branch office firewall to the default Internet Network behind the main office ISA firewall. NOTE that you do not need to use a firewall at the main office, you can use a router. But the ISA firewall configuration is a nice lesson in that the external interface of an ISA firewall doesn’t necessarily have to be directly connected to the default External Network.
Branch office unihomed ISA firewall
IP Addr: 192.168.1.72
DG: 192.168.1.60
DNS: Pubic DNS Svr
The branch office ISA firewall has a single NIC. The NIC has a valid IP address on the branch office network and has a default gateway pointed to my Internet connection. I did this for convenience. I could have changed the network IDs and configured the branch office firewall to connection to the Internet by going through the main office ISA firewall. What matters here is that the default gateway on the branch office ISA firewall should point to a router that is in a path that will forward Internet bound requests to an outbound access point to the Internet.
A routing table entry was configured on the branch office firewall in this VM network so that it had a gateway address to reach the main office network. This enabled the branch office ISA firewall to connect to the Internet using our office’s Internet connection while routing packets destined to the main office to the external interface of the main office’s ISA firewall.
Main office Web servers
Assorted addresses on the main office network
The main office Web servers include SSL and non-SSL Web servers. They all belong to the same domain, which in this example is msfirewall.org. This simulates what the customer had in that all of their Web servers were hosts in the same DNS domain. This enabled us to:
- Use a wildcard certificate for the Web Publishing Rules. The wildcard certificate was good for all servers in the same domain. We did not need to generate new certificates, each with the exact FQDN used by each Web server, to bind multiple Web listeners
- Use a split DNS to control name resolution. Each branch office must be configured with a DNS server that resolves the names of the Web servers to the IP address that the Web Publishing Rule for that server is using. This is required because the Web proxy clients are using Direct Access, not Web proxied connections to connect to these Web servers through the Web Publishing Rules. I’ll go into this in much more detail later in this article
- Create an “external” zone for the corporate domain name at each branch office. This enabled use to simulate the split DNS infrastructure you typically use for external client access to internal Web servers published on the corporate network. What was key is that the Host resource records we entered into the DNS we for the names of the published Web servers and those Host records pointed to the IP addresses used at the specific branch office’s ISA firewall’s Web listeners used to publish the servers.
Branch office client
IP Addr: 192.168.1.1
DG: 192.168.1.60
DNS: 192.168.1.72
The branch office client in the VM network is a Windows XP Service Pack 2 computer configured as a Web Proxy client of the branch office unihomed ISA firewall. The client is configured to use the autoconfiguration script so that the Direct Access settings are pulled from the ISA firewall. You could accomplish the same thing with a .pac file, or by provisioning the browsers via Group Policy to use Direct Access when connecting to the msfirewall.org sites.
The branch office client is configured to use the Internet connection on our network as its default gateway.
Internet connection
In order to set this up, you need to consider or perform the following:
- Configure the IP addressing information on the branch office ISA firewall device NIC The branch office ISA firewall’s single network interface card is configured to use the default gateway used by all other devices on the network. This might be a packet filtering router or another ISA firewall used on the edge of the branch office network. The DNS server configured on the NIC must be able to resolve Internet host names and optionally other names on the corporate network.
- Install the ISA firewall software on the branch office ISA firewall device In this example we’ll install the enterprise version of the ISA firewall at the branch office. The installation procedure on the unihomed ISA firewall is a bit different than we usually see, since we almost always install the ISA firewall in full multi-NIC firewall mode. The key take-away here is that when installing in unihomed firewall mode, all addresses in the IPv4 range are considered part of the default Internal Network (with the exception of the loopback network ID).
- Install and configure the DNS server on the branch office ISA firewall device We need to install a DNS server on the ISA firewall to create the split DNS infrastructure that enables clients to resolve names of main office Web servers to the IP address of the ISA firewall. The DNS server installed on the branch office unihomed ISA firewall is configured with forward and reverse lookup zones for the main office Web server domains. Resource records for the Web servers are then entered into the forward lookup zone.
- Enable caching on the branch office ISA firewall device One of our goals is to cache SSL responses from main office Web servers. We accomplish this by using SSL to SSL bridging and enabling caching on the unihomed ISA firewall.
- Configure Direct Access for the main office domain We need to make sure that the Web proxy clients at the branch offices do not forward connection requires directly to the Web proxy service via the Web proxy service’s Web listener. We can do this by configuring the corporate domain or corporate domain Web servers to use Direct Access when connecting to those sites.
- Create an Access Rule on the ISA firewall device allowing outbound access for the DNS protocol to the Local Host Network An Access Rule enabling outbound access from the default Internal Network to the Local Host Network is required to allow branch office clients access to the DNS server on the ISA firewall.
- Create the Web Publishing Rules for the corporate Web sites Web Publishing Rules are required to provide access to the Web servers on the corporate network. We must use Web Publishing Rules instead of access rules because we need caching of SSL objects obtained from the Web servers on the corporate network. Since the ISA firewall cannot performance forward SSL to SSL bridging, our solution is to obtain access to the SSL encrypted content and cache it via a Web Publishing Rule that provides reverse SSL to SSL bridging.
- Configure Hosts File Entries for the Corporate Web servers We need the ISA firewall device to resolve the name of the Web server to the IP address of the Web server on the corporate network. We do not want the ISA firewall to use the DNS server installed on the ISA firewall itself, because the DNS server resolves the name of the published Web server to the IP address of the ISA firewall itself, which will end up causing a loop condition that we must avoid.
- Create Access Rules allow access to the Internet If you want to allow branch office network clients access to the Internet, then you’ll need to create one or more Access Rules allowing them access. Remember, a unihomed ISA firewall can only support HTTP, HTTPS and Web proxied FTP (HTTP tunneled FTP) connections. All other connections will need to go out the client’s default gateway.
- Configure the clients to use the branch office ISA firewall device as their DNS server The clients on the branch office network need to resolve the names of the main office Web servers to the IP address of the unihomed ISA firewall at the branch office. In order to do this, all clients must be configured to use the IP address of the DNS server installed on the unihomed ISA firewall device.
- Configure the clients as Web Proxy clients In the branch office configuration discussed in this article, we want the unihomed ISA firewall to provide Web proxy services for both Internet connections and connections to the main office Web servers. This requires that the clients be configured as Web proxy or SecureNAT clients of the ISA firewall. The SecureNAT client configuration isn’t official supported, although if you do make the clients SecureNAT clients of the ISA firewall, the Web proxy filter will enable the SecureNAT clients to reach the desired resources.
I’m still debating whether or not to make this a multi-part article series on the step by steps based on the above bullet points to make this work. This article includes all the key elements of the solution but does not provide detailed information on how to fully implement the solution. If you’re a dyed in the wool ISA firewall and network admin, you have enough information here to see how it works and carry it out to fruition. However, if ISA firewall networking isn’t your full time job, but you’re interested in the step by steps, then let me know. If I can get five people who are interested in me continuing this article into an implementation series, then I will. Otherwise, I’ll move on to other things.
Summary
In this article we departed a bit from our usual approach to the ISA firewall as network firewall and focused on the ISA firewall’s Web proxy filter and caching feature set. In the scenario discussed in this article, we used the ISA firewall’s Web proxy filter and caching to provide what is in essence a forward SSL to SSL bridging scenario, enabling the ISA firewall to perform application layer inspection for “forward” SSL Web proxy requests to the main office’s Web servers. This type of outbound SSL bridging was accomplished by using a combination of a split DNS infrastructure and SSL Web Publishing Rules.
