Publishing Multiple Web Sites using Web Publishing Rules

Publishing Multiple Web Sites using Web Publishing Rules
By Thomas W Shinder M.D.


If you haven’t been able to tell by now, the feature I like the most about ISA Server is Web Publishing. Web Publishing Rules allow you to do allow you to do all sorts of things you can’t do with Server Publishing Rules. Here are just a few of the cool tricks you can do with Web Publishing Rules:



  • Publish multiple Web sites with a single IP address on the external interface of the ISA Server
  • Perform port redirection to allow internal Web servers to listen on alternate port numbers
  • Perform protocol redirection that allows incoming HTTP or HTTPS requests to be forwarded as FTP requests
  • Carry out SSL bridging – this allows you to terminate an SSL connection on the external interface of the ISA Server and then bridge that connection as either HTTP or SSL to the internal network server
  • Use basic, integrated, digest or client certificate authentication to gain access to an Incoming Web Requests listener
  • Impersonate internal Web servers by binding the Web server certificate to the Incoming Web Requests listener used to accept requests for the internal Web server

  • The Web Proxy service provides the intelligence behind Web Publishing Rules. Unlike Server Publishing Rules, Web Publishing Rules take advantage of the Web Proxy service’s ability to examine HTTP header information and make decisions about how to route requests based on header information.


    Get the Book!


    For example, the Web Proxy service is able to take the destination URL contained in an incoming request and compare that to URLs included in Destination Sets that are part of Web Publishing Rules. The first Web Publishing Rule that contains a matching URL in its Destination Set is applied to the incoming request.


    You can publish multiple internal Web servers using a single IP address on the external interface of the ISA Server. You must use Web Publishing Rules to accomplish this task. Web Publishing Rules depend on the Web Proxy service, which means you have to install the ISA Server in either Integrated or Web Caching mode. You can’t create Web Publishing Rules if you install the ISA Server in firewall mode.


    The figure below shows a typical Web Publishing scenario. The ISA Server is installed in Integrated mode and there are two IP addresses bound to the external interface. In this example, the external IP addresses are 1.1.1.1 and 1.1.1.2. There are three physical servers on the internal network that house a total of 4 Web sites. Server1 has a single Web site, as does Server2. There are two Web sites on Server3. One of the Web sites listens on TCP port 80 and the other Web site listens on TCP port 8866.



    Things you need to take care of when publishing multiple Web sites include:



  • Creating Public DNS Server Records
  • Configuring the Incoming Web Requests listeners
  • Creating the Web Publishing Rules

  • Let’s look at each of these issues in more detail.


    ———————————


    Creating the Public DNS Records


    ———————————


    This is probably the most troublesome issues for neophyte ISA Server administrators. It’s imperative that you have public DNS entries for the sites that you want to publish using Web Publishing Rules. The Web Proxy service needs to evaluate FQDNs in the URLs it processes (as well as the path) to make intelligent decisions regarding which Web Publishing Rule should be assigned responsibility for an incoming request. You cannot use IP addresses in your Destination Sets if you want to publish multiple Web sites with a single IP address on the external interface of the ISA Server.


    In our current example, we need to create the following Host (A) records on a public DNS Server (the DNS server can be hosted by a third party, or you can host your own DNS server, its doesn’t matter who hosts the server; what’s important is that the server is publicly accessible):


    www.domain.com 1.1.1.1


    web1.domain.com 1.1.1.1


    web2.domain.com 1.1.1.2


    web3.domain.com 1.1.1.2


    Notice that www.domain.com and web1.domain.com both resolve to the same IP address and web2.domain.com and web3.domain.com resolve to the same IP address. This doesn’t create problems for Web Publishing Rules because the Web Proxy service can decide how to handle incoming requests based on the URL contained in the request.


    ———————————


    Creating the Incoming Web Requests Listeners


    ———————————


    The Web Proxy service depends on an Incoming Web Requests listener to accept incoming HTTP connections. You can access the Incoming Web Requests listener configuration interface by right clicking on your server name in the ISA Management console and clicking the Properties command. Click on the Incoming Web Requests tab and you’ll see what appears below.


    If you have a single IP address bound to the external interface of the ISA Server, you can select the Use the same listener configuration for all IP addresses option, since the single IP address represents all of your IP addresses. You should select the Configure listeners individually per IP address option if you have more than one IP address bound to the external interface of the ISA Server. While you don’t have to do it this way, configuring each IP address as an individual listener provides you a lot more flexibility.



    Click the Add button to access the Add/Edit Listeners dialog box. Select your Server name, select the IP Address and type in a Display name. You have the option to Use a server certificate to authenticate to Web clients. This option allows you to bind a Web Server certificate to this Incoming Web Requests listener, which sets things up so the listener can impersonate the Web server on the internal network. Select the authentication methods you want to support. If you select the Basic or Digest authentication methods, I highly recommend that you select a default domain, as this will improve performance.



    Click OK in the Add/Edit Listeners dialog box. This added the first listener. I’ll repeat the process so that we have separate listeners for 1.1.1.1 and 1.1.1.2. The figure below shows what the Incoming Web Requests listener tab looks like after the two listeners are configured.



    It’s important to note that the Incoming Web Requests listener represents a socket which accepts incoming HTTP requests. There is no direct connection between a particular Web Publishing Rule and a specific Incoming Web Requests listener. That is to say, you don’t configure a Web Publishing Rule to use a specific Incoming Web Requests listener. The listener that services a particular request is determined by name resolution for the FQDN the external user uses to access the Web site.


    For example, www.domain.com resolves to 1.1.1.1. Whenever someone tries to access www.domain.com, they will connect with the Incoming Web Requests listener that uses IP address 1.1.1.1. The listener accepts the request and forwards it to the Web Proxy service. The Web Proxy service compares the URL (which in this case is www.domain.com) in the request with the URLs contained in the Destination Sets in the Web Publishing Rules. If there’s a match, the matching rule determines how the request is handled.


    Get the New Book!


    ———————————


    Creating the Web Publishing Rules


    ———————————


    Let’s look at our network diagram again:



    What we want to do is create four Web Publishing Rules. Two of the rules will use the Incoming Web Requests listener using 1.1.1.1, and two of the rules will use the Incoming Web requests listener using 1.1.1.2. Let’s take a close look at the rules.


    Web Publishing Rule1


    This rule uses a Destination Set that contains the URL www.domain.com. The FQDN www.domain.com resolves to 1.1.1.1. When the Incoming Web Request listener picks up the request for www.domain.com, it will forward it to the Web Proxy service. The Web Proxy service will find that Web Publishing Rule 1 uses a Destination Set containing the URL www.domain.com. This rule is configured to redirect the request the internal network Web server named Server1 on its TCP port 80.


     


    Web Publishing Rule 2


    This rule uses a Destination Set that contains the URL web1.domain.com. The FQDN web1.domain.com resolves to 1.1.1.1, which is the same IP address used by www.domain.com and Web Publishing Rule 1. However, when the Incoming Web Requests listener on IP address 1.1.1.1 picks up this request, it forwards the request to the Web Proxy service and the Web Proxy service see the URL as web1.domain.com. The Web Publishing Rule 2 is configured to redirect the request to the internal network server Server2 on its TCP port 80. Notice the magic performed by the Web Proxy service! Requests for www.domain.com and web1.domain.com arrive at the same IP address on the external interface of the ISA Server and the Web Proxy service can decide what to do with the requests because they have different URLs. This is why you never want to use an IP address in the Destination Sets you use to publish Web sites.


     


    Web Publishing Rule 3


    This rule uses a Destination Set that contains the URL web2.domain.com. The FQDN web2.domain.com resolves to 1.1.1.2. When the Incoming Web Request listener picks up the request for web2.domain.com, it will forward it to the Web Proxy service. The Web Proxy service will find that Web Publishing Rule 3 uses a Destination Set containing the URL web2.domain.com. This rule is configured to redirect the request the internal network Web server named Server3 on its TCP port 80.


     


    Web Publishing Rule 4


    This rule uses a Destination Set that contains the URL web3.domain.com. The FQDN web3.domain.com resolves to 1.1.1.2, which is the same IP address used by web2.domain.com and Web Publishing Rule 3. However, when the Incoming Web Requests listener on IP address 1.1.1.2 picks up this request, it forwards the request to the Web Proxy service and the Web Proxy service see the URL as web3.domain.com. The Web Publishing Rule 4 is configured to redirect the request to the internal network server Server3 on its TCP port 8866. Again, note the magic performed by the Web Proxy service! Requests for web3.domain.com and web2.domain.com arrive at the same IP address on the external interface of the ISA Server and the Web Proxy service decides what to do with the requests because they have different URLs. In this case, Web Publishing Rule 4 forwards the request to the same server on the internal network that Web Publishing Rule 3 does, but it forwards it to a different port number. This is one example of the type of port redirection you can do with Web Publishing Rules.


     


    Get the Book!


     


    ———————————


    Summary


    ———————————


    Web Publishing Rules allow you to publish multiple Web sites using a single IP address on the external interface of the ISA Server. Publishing multiple Web sites using a single IP address on the external interface is easy, as long as you as you use FQDNs in your Destination Sets. Your attempts to publish multiple servers on the internal network with a single IP address will usually fail if you use IP addresses in the Destination Sets used by your Web Publishing Rules. Make sure your published servers have entries in the public DNS and that they resolve to IP addresses used by your Incoming Web Requests listeners.


    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=5;t=001295 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

    1 thought on “Publishing Multiple Web Sites using Web Publishing Rules”

    1. Use a computer name or IP address to connect to the published server but in multiple websites publishing it is not asking for ip address of server which is hosting website.

    Leave a Comment

    Your email address will not be published. Required fields are marked *

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

    Scroll to Top