Publishing Multiple Non-SSL Web Sites with a Single IP Address using ISA Firewalls

Publishing Multiple Non-SSL Web Sites with a Single IP Address using ISA Firewalls
By Thomas W Shinder MD, MVP







Have Questions about the article? 
Ask them  HERE



One of the very cool things you can do with ISA firewall is publish multiple Web sites using a single IP address on the external interface. You can use a single IP address on the external interface of the ISA firewall to publish multiple sites, or if you have a hundred addresses on the external interface. The ISA firewall’s Web proxy filter component is what makes it all happen.


Unlike simple stateful packet inspection firewalls that can only do “port forwarding” or reverse NAT, the ISA firewall supplements its stateful packet inspection engine with a Web proxy filter that communicates with the ISA firewall services. The ISA firewall’s Web proxy filter extends the ISA firewall’s stateful packet inspection feature set by adding stateful application layer inspection. The Web proxy filter’s application layer inspection is what enables you to publish multiple Web sites using a single IP address.


In this article we’ll do the following:



  • Examine the differences between how simple stateful inspection firewalls and advanced application layer inspection firewalls (like ISA) handle publishing multiple sites
    Simple stateful packet inspection firewalls and NAT devices are unable to perform advanced inspection of HTTP protocol headers. Here you’ll learn the differences and see why the ISA firewall rocks and why hardware firewalls can’t face muster
  • Describe the example publishing environment used in this article
    Here I’ll give a high level overview of the lab network and provide you a chart with the name and IP addressing details
  • Publish the two Web sites using Web Publishing Rules
    This is the meat and potatoes of the article. Here you’ll create the two Web Publishing Rules that allow you to publish multiple Web sites using a single IP address on the external interface of the ISA firewall

In this article I’m going to try something new. There are often so many processes and procedures covered in a single article that it’s hard to tell the forest from the trees. I run into the same problem myself when going over documents that include multiple procedures and I end up getting lost. I’ve been trying to figure out how to solve this problem and I think a flow chart might help. Let me know how this works for you and if you have any suggestions on how to make it more effective, let me know. The chart for this article appears below.




Figure 1: Flowchart for this article


Contrasting How Simple Stateful Packet Inspection Devices handle Web Publishing Compared to Advanced Application Inspection Firewalls (ISA)


The figure below shows what happens when you try to provide remote access to Web sites using a simple stateful packet inspection firewall or NAT device.



  1. The external client enters the name of the site into the Web browser and this generates a DNS query to an external DNS server. For example, the external client sends a query for the Host (A) record for www.msfirewall.org. The DNS returns the address 192.168.1.71.
  2. The external client sends a GET request to 192.168.1.71 and includes in the application layer Host Header the name www.msfirewall.org. The connection request arrives on the external interface of the stateful packet inspection device. The device has a rule that says to forward all incoming connections on 192.168.1.71 TCP 80 to 10.0.0.11 TCP 80. That’s it. The simple stateful packet inspection device does not have the ability to inspect application layer information and completely ignores the Host Header.
  3. The connection request is forwarded to the Web server on the internal network listening on 10.0.0.11 TCP 80.



Figure 2: Simple stateful packet inspection device is unable to make intelligent decisions based on application layer header information


So far, things seem to be working reasonably well with the simple packet inspection device. But what happens when you have only a single IP address on the external interface of the stateful packet inspection device and you want to publish a second Web site on the internal network? It won’t work, because the first socket (a combination of transport protocol, IP address and port) is taken by the first port forwarding rule.


There is no information in the layer 3 (or below) header that enables the simple stateful packet inspection device to figure out what Web site the connection should go to, all it knows is if it receives a connection on a certain IP address, protocol and port, then it must follow a rule that tells it to send the connection to a specific IP address, protocol and port.


There are some alternatives. You could use host headers on the internal sites to differentiate one from another, but each of those sites must be hosted on the same Web server since the port forwarding rule can only forward to the same IP address.


The are several problems with this approach, including the fact that not all Web servers support host headers which would allow multiple sites on a single IP address, when SSL is required and when all the sites are hosted on the same physical Web server. If Host Headers won’t work, another option is to assign each site to a different port. However, this can become problematic because external users need to remember which port to use and if you’re using a different post on the internal network, those same users will need to remember which port to use to access the same resources when they are located on the internal network.


In contrast to the simple stateful packet inspection device is the ISA firewall. The ISA firewall is a stateful packet inspection firewall and much more. The ISA firewall provides both stateful packet and application layer inspection. The ISA firewall’s Web proxy filter is able to work with the ISA firewall’s stateful packet inspection engine and receive connection information after the communication is cleared by the firewall engine components. The Web proxy filter performs that application layer inspection after packet inspection is completed.


The figure below shows how things work when you bring the ISA firewall’s intelligent application layer inspection engine into the mix:



  1. The external user enters www.msfirewall.org into the browser and a DNS query is sent to an external DNS server for this name. The IP address 192.168.1.71 is returned by the DNS server.
  2. The external client then sends a GET request to 192.168.1.71 TCP 80 with the HTTP Host Header www.msfirewall.org included in the request. The ISA firewall performs stateful packet inspection on the communication and once the connection is cleared, the information is forwarded to the Web proxy filter. The Web proxy filter examines the application layer information. In this case, the application layer information of interest is the Host Header. The Web proxy filter on the ISA firewall determines that the request is for www.msfirewall.org.
  3. A Web Publishing Rule on the ISA firewall is configured to forward requests for www.msfirewall.org to www.msfirewall.org on the internal network. The request is forwarded to the Web site listening on 10.0.0.11 which resolves to www.msfirewall.org on the internal network.
  4. In the second scenario, in step 1, the Web browser makes a request for www2.msfirewall.org and a DNS query to a public DNS server resolves the request to IP address 192.168.1.71. The Web browser sends a GET request to IP address 192.168.1.71 with a Host Header www2.msfirewall.org included in the request.
  5. The ISA firewall is configured with a Web Publishing Rule that is configured to forward HTTP requests for www2.msfirewall.org to a Web site on the internal network that resolves to www2.msfirewall.org when using an internal network DNS server. In this example, www2.msfirewall.org on the internal network resolves to the IP address 10.0.0.12.



Figure 3: Stateful application layer inspection firewalls like the ISA firewall can examine HTTP application layer headers and make intelligent decisions based on this information


Note in the examples that the ISA firewall is using a private address on the external interface. I’m doing this because these are the addresses we will use in the step by step examples used in this article. In an actual live network deployment, the public DNS server will not have a public DNS record using a private IP address. Instead, the public DNS server records point to a public address used to access the published Web site. The public address could be one bound to the external interface of the ISA firewall, or to the external interface of a NAT device in front of the ISA firewall.







Have Questions about the article? 
Ask them  HERE



Network Environment Used in this Article


In this article, we will publish two Web sites that are located on the same IIS 6.0 Web server. Pertinent information about the Web sites is in the table below.


























Site Name/Feature


Web Site 1


Web Site 2


Public Name


www.msfirewall.org


www2.msfirewall.org


Public IP address


192.168.1.71


192.168.1.71


Private Name


www.msfirewall.org


www2.msfirewall.org


Private IP address


10.0.0.11


10.0.0.12

Table 1: Web site names and IP addresses


Both Web sites will be accessible from the same IP address, thus demonstrating how to publish multiple sites with a single IP address. In this example I use ISA firewall best practices by deploying a split DNS infrastructure and using the same domain name for internal and externally accessible resources.


The split DNS infrastructure enables you to provide access to Web resources to both internal and external clients using the same name. The split DNS infrastructure provides you the strategic benefits of:



  • Simplifying access so that users do not need to use different names depending on their current location
  • Prevent the ISA firewall worst practice of looping back through the ISA firewall to access resources on the same ISA firewall Network from which the resource was requested

When using a split DNS infrastructure, the ISA firewall will resolve the fully qualified name of the published Web server to the IP address of the Web site on the internal network. The ISA firewall must never resolve the names of published Web sites to the external address on the ISA firewall used by external users to access the site.


Even though we are using the same second-level domain name for the two Web sites, there is no limitation in this area. I could have published two sites, like www.msfirewall.org and www.isafirewall.org using a single IP address using the same methods that we’ll use to publish the two sites listed in the table. The procedures are exactly the same.


Note that things get a bit more tricky if you plan on publishing SSL sites. The reason for this is that the common/subject names on the certificates bound to the Web listeners and the actual Web sites have profound influence over what you can and cannot do when publishing multiple Web sites. I’ll discuss how to publish multiple SSL sites using a single IP address in another article.



WARNING:
One last thing. This article does not provide comprehensive coverage of Web Publishing Rules and how they work. There are security configurations and nuances that aren’t exposed by the Web Publishing Rule Wizard. For detailed coverage of Web Publishing Rules and how to get the most out of them, check out our book Configuring ISA Server 2004.


Publishing the Web Sites using ISA Firewall Web Publishing Rules


I will assume that you have already installed the ISA firewall software, but haven’t yet created any Web Publishing Rules or Web listeners.


The first step is to create a Web listener. You don’t have to create the Web listener first, as you can create the Web listener on the fly when creating the Web Publishing Rule. But I like to do things differently from time to time. So on this occasion we’ll depart from our usual M.O. and create the Web listener first.


Create the Web Listener


Perform the following steps to create the Web listener:



  1. In ISA firewall console, expand the server name in the left pane of the console and click the Firewall Policy node. Click the Toolbox tab and then click the Network Object header. Click the New menu and then click Web Listener.
  2. On the Welcome to the new Web Listener Wizard page, enter a name for the listener in the Web listener name text box. In this example we’ll name the listener HTTP Listener and click Next.
  3. On the IP Addresses page, put a checkmark in the External checkbox and click Next.



Figure 4



  1. On the Port Specification page, confirm that the Enable HTTP checkbox is enabled and that HTTP port is listed as 80.  Make sure that the Enable SSL checkbox is not enabled. We do not want this listener to service SSL requests. I’ll show you how to publish multiple SSL Web sites in another article. Click Next.
  2. Click Finish on the Completing the New Web Listener Wizard page.

Create the Web Publishing Rule for www.msfirewall.org


Now that we have a Web listener in place, we can create the first Web Publishing Rule. Perform the following steps to create the Web Publishing Rule for the www.msfirewall.org Web site that is listening on 10.0.0.11 on the internal network:



  1. In the ISA firewall console, expand the server name and click the Firewall Policy node. In the Task Pane, click the Tasks tab and click the Publish a Web Server link.
  2. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the Web Publishing Rule in the Web Publishing Rule name text box. In the example, we’ll name the rule WWW Site. Click Next.
  3. Click Allow on the Select Rule Action page.
  4. On the Define to Website to Publish page, enter the name of the Web site on the internal network in the Computer name or IP address text box. Note that this name must resolve to the IP address that the internal Web site is listening on. In this example, the www.msfirewall.org is listening on 10.0.0.11 and there is a DNS entry on the internal DNS server that resolves this name to that IP address. We want to allow access to all files and folders on the Web site, so we will enter /* in the Path text box. Click Next.



Figure 5



  1. On the Public Name Details page, select the This domain name (type below) option in the Accept requests for drop down list. In the Public name text box, enter www.msfirewall.org. This is the name that external users will use to access the site and this is the name that must be included in the Host Header in the request. For example, users must access the site using http://www.msfirewall.org. They cannot use http://192.168.1.71, since that would not include www.msfirewall.org in the Host Header. Click Next.
  2. On the Select Web Listener page, select the HTTP Listener entry from the Web listener drop down list and click Next.
  3. Click Next on the User Sets page.
  4. Click Finish on the Completing the New Web Publishing Rule Wizard page.

Create the Web Publishing Rule for www2.msfirewall.org


Now let’s create the Web Publishing Rule for www2.msfirewall.org:



  1. In the ISA firewall console, expand the server name and click the Firewall Policy node. In the Task Pane, click the Tasks tab and click the Publish a Web Server link.
  2. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the Web Publishing Rule in the Web Publishing Rule name text box. In the example, we’ll name the rule WWW2 Site. Click Next.
  3. Click Allow on the Select Rule Action page.
  4. On the Define to Website to Publish page, enter the name of the Web site on the internal network in the Computer name or IP address text box. Note that this name must resolve to the IP address that the internal Web site is listening on. In this example, the www2.msfirewall.org is listening on 10.0.0.12 and there is a DNS entry on the internal DNS server that resolves this name to that IP address. We want to allow access to all files and folders on the Web site, so we will enter /* in the Path text box. Click Next.



Figure 6



  1. On the Public Name Details page, select the This domain name (type below) option in the Accept requests for drop down list. In the Public name text box, enter www2.msfirewall.org. This is the name that external users will use to access the site and this is the name that must be included in the Host Header in the request. For example, users must access the site using http://www2.msfirewall.org. They cannot use http://192.168.1.71, since that would not include www2.msfirewall.org in the Host Header. Click Next.
  2. On the Select Web Listener page, select the HTTP Listener entry from the Web listener drop down list and click Next.
  3. Click Next on the User Sets page.
  4. Click Finish on the Completing the New Web Publishing Rule Wizard page.

Test the Solution


Now let’s test the solution. On an external client machine, enter www.msfirewall.org in Internet Explorer. You should see the default home page for that site.


Do the same thing for www2.msfirewall.org. You should see the default home page for that site.


OK, that wasn’t very exciting, but you get the point – that you are able to publish two Web sites using a single IP address on the external interface of the ISA firewall. Note that this test only works when you configure the external client with a DNS server address that resolves www.msfirewall.org and www2.msfirewall.org to the IP address used by the Web Listener that accepts incoming connections for the two Web Publishing Rules you created.







Have Questions about the article? 
Ask them  HERE



Summary


In this article we examined the differences between simple stateful packet inspection firewalls and advanced application layer inspection firewalls like the ISA firewall. We then went over the lab network and the assumptions made for the network. Web Publishing Rules were used to provide access to two different Web sites, both accessible from the same IP address on the external interface of the ISA firewall. We finished up the article by testing access to the two published Web sites.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top