Enabling Secure SSL OWA Access through the ISA Firewall:
Part 1: Learning the Basics with HTTP to HTTP Bridging
By Thomas W Shinder MD, MVP
Got Questions? Go to:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000416 and ask!
One the of key technologies that sets the ISA firewall apart from typical stateful packet inspection (SPI) firewalls is its ability to perform SSL to SSL bridging for secure remote access to Web sites published through the ISA firewall. The exceptional level of security provided by the ISA firewall obviates any reason for considering a dedicated so-called “SSL VPN” device for your network. In fact, the ISA firewall acts as SSL gateway for secure remote access to SSL secured Web sites (within the purview of the many and varied definitions of so-called “SSL VPNs”). This is especially true when connecting to secure OWA sites through the ISA firewall.
However, for those of you new to stateful application layer inspection of SSL tunneled data, the procedures involved might not immediately make sense. To get you up and running with your secure OWA and Web site publishing through the ISA firewall, we’ll present a two part series on how the ISA firewall handles remote access to Web sites using Web Publishing Rules.
In this, the first part of the two part series, we’ll focus first on some of the mechanics of HTTP to HTTP bridging. This isn’t a comprehensive discussion of Web Publishing, as we took care of that task in our book Configuring ISA Server 2004. However, once you review the information in the book about how to configure a Web Publishing Rule, you should read this article to get a better handle on how the ISA firewall handles “bridging”. The ISA firewall’s bridging feature enables is to receive a connection from a remote client using one protocol, and then forwarding it using the same or alternate protocol. Examples of bridging include HTTP to HTTP bridging, SSL to SSL bridging, and SSL to HTTP bridging. The latter is not recommended and will not be discussed in this series.
In the second part of this series we’ll look at how SSL to SSL bridging works and explain some of the key settings that get most ISA firewall admins in trouble.
HTTP to HTTP Bridging with Host Header Forwarding Enabled when Accessing an OWA Web Site
Let’s see how things work with HTTP to HTTP bridging for OWA Web site publishing. The advantage of starting with studying HTTP to HTTP bridging is that we can see all the header information in Network Monitor because its not encrypted. We won’t be able to see the HTTP header information when we capture the SSL frames, because Network Monitors captures information at the frame (layer 2) level, so the application layer components are still encrypted.
In the first example we’ll look at what happens with an HTTP to HTTP Web Publishing Rule that publishes the scenario depicted in the figure below.
This figure shows the Web client on the Internet sending an HTTP GET request to public.msfirewall.org. The Web listener used in the Web Publishing Rule that publishes the Exchange Server’s OWA site on the corporate network receives the connection on the ISA firewall’s external interface. A Web site certificate with the common/subject name public.msfirewall.org is bound to the Web listener, but that won’t be an issue at this time because we’re using HTTP to HTTP bridging. It will be a big issue when we do SSL to SSL bridging.
In this example, the Web Publishing Rule’s Public Name tab is configured to accept connections from public.msfirewall.org. The Server text box on the To tab is configured to forward the connection to private.msfirewall.org. The entry in the Server text box is used by the ISA firewall to identify the server the incoming request will be forwarded to. The Forward the original host header instead of the actual one (specified above) option determines whether the HTTP Host Header sent the external client is forwarded to the published Web site, or if the entry in the Server text box is forwarded as the HTTP Host Header entry forwarded to the published Web site.
For OWA Web Publishing Rules, the Forward the original host header instead of the actual one (specified above) option is enabled by default when you use the Mail Server Publishing Rule wizard. Note that even thought you think the “actual” host header would be the one sent by the OWA client on the Internet, the ISA firewall’s Web Publishing Rule considers the entry in the Server text box to be the actual host header.
Therefore, when the Forward the original host header instead of the actual one (specified above) option is selected, we should expect that the connection request from the remote client will be forwarded to public.msfirewall.org, since the latter is the HTTP Host Header sent by the remote Web client.
In the figure below you can see the requests coming from the external client (192.168.1.187) to the ISA firewall. The Web Proxy Filter forwards the request to http://private.msfirewall.org and there is a destination host name of public.msfirewall.org, though this is derived from the OWA client request. It’s interesting that the URL includes the name in the Server text box instead of the host header. This indicates that regardless of how you configure host header forwarding, the request URL will include the name included in the Server text box on the To tab.
(Keep these entries in mind as they’ll become critically important when we talk about SSL to SSL bridging.)
The log file entries below are from the published site on the corporate network’s IIS W3CSVC log file. You can see the entries are for public.msfirewall.org, indicating that the original host header entry (public.msfirewall.org) was sent to the Web server.
=========================================
2005-03-09 11:29:58 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/ – 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) – public.msfirewall.org 401 2 2148074254
2005-03-09 11:30:09 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/ – 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) – public.msfirewall.org 401 1 0
2005-03-09 11:30:12 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/ – 80 msfirewall\administrator 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) – public.msfirewall.org 200 0 0
2005-03-09 11:30:12 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/Administrator/Inbox/ Cmd=contents 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) http://public.msfirewall.org/exchange/ public.msfirewall.org 401 2 2148074254
2005-03-09 11:30:12 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/Administrator/Inbox/ Cmd=contents 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) http://public.msfirewall.org/exchange/ public.msfirewall.org 401 1 0
2005-03-09 11:30:14 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/Administrator/ Cmd=navbar 80 msfirewall\administrator 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) http://public.msfirewall.org/exchange/ public.msfirewall.org 200 0 0
2005-03-09 11:30:14 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/Administrator/Inbox/ Cmd=contents 80 msfirewall\administrator 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) http://public.msfirewall.org/exchange/ public.msfirewall.org 200 0 0
2005-03-09 11:30:18 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchweb/6.5.7226.0/controls/tf_TwoLine.xsl – 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) http://public.msfirewall.org/exchange/Administrator/Inbox/?Cmd=contents public.msfirewall.org 200 0 0
=========================================
We can also see that the original HTTP Host Header was sent to the published Web site in the network Monitor trace below. This was taken at the computer hosting the published Web site. You can see the HTTP: Host =public.msfirewall.org line proves the original host header was sent to the Web server on this machine from the ISA firewall.
The connection to the published Web site was successful and the external client was able to access the OWA Web site over the HTTP to HTTP bridged connection.
HTTP to HTTP Bridging with Host Header Forwarding Disabled When Accessing an OWA Web Site
What would happen if we disabled host header forwarding for this rule?
What should happen is that the ISA firewall should forward the entry in the Server text box on the To tab in the Web Publishing Rule as the HTTP Host Header name and use the Server text box entry on the To tab to resolve the name of the published Web server on the corporate network.
The log files entries on the ISA firewall in this scenario are just about the same as that we say when the original client HTTP Host Header was forwarded to the published Web site, as seen in the figure below.
However, the situation is quite different when we examine the Web service log files and the Network Monitor trace on the Web site. Notice in the Web site W3SVC log file below that the requests are to private.msfirewall.org, which represents not the original HTTP Host Header sent by the external Web client, but the HTTP Host Header sent by the ISA firewall based on the Server text box entry on the To tab of the Web Publishing Rule.
=========================================
2005-03-09 11:57:55 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/ – 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) – private.msfirewall.org 401 2 2148074254
2005-03-09 11:57:59 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/ – 80 – 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) – private.msfirewall.org 401 1 0
2005-03-09 11:57:59 W3SVC1 EXCHANGE2003BE 10.0.0.2 GET /exchange/ – 80 msfirewall\administrator 10.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) – private.msfirewall.org 200 0 0
=========================================
In the Network Monitor trace taken at the published Web server below you can see the HTTP: Host =private.msfirewall.org represents the HTTP Host Header sent by the ISA firewall to the published Web site.
If we look at the data included in the response from the Web site back to the ISA firewall, you’ll see what appears in the figure below. You’ll see in the data portion that the BASE href=http://private.msfirewall.org… This is generated by the OWA site’s Web page code that dynamically generates links based on the HTTP Host Header information sent to the OWA Web site.
These are “hard coded links” and are not exposed to the default link translation provided by the ISA firewall when requests are made to relative links (such as <a href=”/content/isa/exchange/”>public.msfirewall.org/exchange/</a>). With relative links, it doesn’t matter what the host header entry is in the request forwarded from the ISA firewall to the Web site. The ISA firewall will automatically append the same FQDN used in the request to the URI (the portion of the HTTP request after the host name. With hard coded links that include the complete URL, then you’ll need to configure link translation dictionary entries to insure that the correct host name is returned to the client.
This information is returned to the external Web client. Since private.msfirewall.org is not an externally resolvable name (not a valid name on the external network/Internet), then the client connection fails. The figure below shows what the client sees in the browser.
Now let’s have some fun.
What if we add a HOSTS file entry on the external host so that it resolves the name private.msfirewall.org to the IP address on the external interface of the ISA firewall that’s being used by the Web listener in the Web Publishing Rule?
If you do this, the client will see what appears in the figure below. The 403 error code indicates that the ISA firewall blocked the connection because the FQDN in the request did not match the entry on the Public tab of the Web Publishing Rule.
We can prove this hypothesis by adding private.msfirewall.org to the Public Name tab on the Web Publishing Rule. Once we add the private.msfirewall.org name to the Public Name tab, we see what appears in the figure below.
So what have we learned about Web Publishing Rules for OWA Web sites?
Summary
In this article we examined some of the characteristics of HTTP to HTTP bridging and the importance of the settings on the Public Name and To tab. This information will provide you with critical understanding of how the ISA firewall forwards HTTP Host Header information to the published Web site, and how HTTP requests are forwarded to the published Web site. In the second article in this series, we’ll build on what you learned in this article and examine how these factors come into play when publishing secure Web sites, with a focus on publishing secure OWA Web sites.
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=23;t=000416 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.
