ISA Server allows you to make internal resources, such a web servers, email servers and FTP servers, available to Internet users. This process of making internal services available to users on an external network is called “Publishing”. When you Publish a service on your internal, private network, you allows selective access to external users.

The actual procedure for publishing a service is very easy, as it is wizard driven. However, before you publish, you have to make sure a couple of infrastructure issues and ISA Server components are set up before you successfully publish your site. In this article we’ll look at the preparations you need to make before publishing a web site.

Prior to publishing your site, you need to deal with the following issues:

• DNS Entries
• Destination Sets
• ISA client configuration
• ISA Server Inbound Web Request Listener

Let’s look at each of these issues and how to handle them before beginning the actual publishing of our web site.

DNS Entries

Users on the Internet will access your published web site via a Fully Qualified Domain Name (FQDN), such as www.isaserver.org. That FQDN must be translated to an IP address before the user can connect to your site. This is the job of a DNS Server. Before you publish your site, you must have a DNS entry for your site on a publicly available DNS server.

Most people will have DNS entries handled by their ISP. You do have the option of hosting your own public DNS Servers. If you are managing your own public DNS servers (and you must have two, although some people cheat and report two IP addresses on the same server), you need to include a Host (A) entry for the internal web server you wish to publihs. For example, if you are managing your own DNS, and have a zone for “domain.com”, you must create a Host (A) record for “www”, if you wish people to access your internal web server www.domain.com.

Your site may also be accessible via multiple names, such as ftp.domain.com, www.domain.com, and mail.domain.com. You can enter multiple Host (A) entries; one for each host name, or you can make a single Host (A) entry and use CNAME (alias) records for the other names. The CNAME approach is a bit easier to manage if you change your IP address from time to time.

Alternatively, you could forget about DNS entries, and make everyone connect to your web site via an IP address. While this is doable, most people can hardly remember their own phone number, much less a 12 digit IP address.

Destination Sets

Once you’ve got the DNS issues handled, you’re ready to create a destination set for your site. A destination set is used by ISA Server to identify which site is requested by the external user. Remember, when working with destination sets and publishing, you are looking at it from the vantage point of the external user, not the internal user. The destination for the external user is going to the FQDN of your site.

Let’s say we want to create a destination set for our site. The internal server we want to publish will answer to the names mail.domain.com and www.domain.com. We can create a single destination set that contains all three of these destinations. Then we can use this destination set in our publishing rule.

1. Open the ISA Management console, and expand the Servers and Arrays node. The expand the Policy Elements node.
2. Right click on the Destination Sets node, click the New command and then click Set.
3. You’ll be presented with the New Destination Set dialog box as it appears below.

   

4. Enter the name of the destination set in the Name text box. Enter a description for the destination set in the Description (optional) text box. You should put each of your destinations in the Description text box because it will make it easier for you to figure out what the destination set is pointing to when you configure your publishing rules. The reason for this is that the description information will appear in the wizards, making it easy for you to figure out what sites the destination set references.
5. To add a new destination to the set, click the Add button. You will see the Add/Edit destinationdialog box as seen below.

   

6. In the Add/Edit Destination dialog box, type in the FQDN for your site in the Destination text box. Note that you can use an asterisk as a wild card to represent all the host names in a domain. After entering the FQDN, click OK.

After creating the destination set, it will appear in the right pane of the ISA Management console. When the ISA Server receives a request for one of these destinations, it will actually examine the headers in the request and see if it has the destination listed in the header included in a destination set for a published server.

ISA Client Configuration

The server you want to publish should be configured as a SecureNAT client. This is a departure from how it was done in Proxy Server 2.0, where the only way you could publish a server was by making the server a Winsock Proxy client and then hammering away at a wspcfg.ini file. ISA Server allows you to escape that pain by configuring published servers as SecureNAT clients.

SecureNAT client configuration is easy. The only thing you need to do is set the default gateway on the server to an address that routes Internet bound requests to the internal interface of the ISA Server. If the published server is on the same logical network ID as the internal interface of the ISA Server, you can set the default gateway to be the IP address of the internal interface of the ISA Server. If the server to be published is on a logical network ID removed from the internal network interface of the ISA server, then you must configure the default gateway on the server to be a router interface that will route packets destined for the Internet to the internal interface of the ISA Server.

If you are working with a routed network, you must make sure that the routing table on the ISA Server is properly configured before even setting up ISA Server. Remember that packets need to know the path from the ISA Server to all subnets on the internal network, and all the subnets need to know the path to the internal interface of the ISA Server. In order for the ISA Server to know the paths to the internal network IDs, you must configure the routing table on the ISA Server with the appropriate gateway address(es) for each of the internal network IDs. You must configure the routing table, because you cannot configure a default gateway on the internal interface. Windows 2000 supports a single network adapter with a default gateway, and that adapter must be the external interface of the ISA Server.

Some services may not work correctly using SecureNAT. You’ll see this if you plan on publishing certain Internet enabled multiplayer games. In this case, you’ll need to configure the server as a Firewall Client and then configure a wspcfg.ini file on that server. If that sounds too painful, you can place the game server on a DMZ segment and create packet filters to allow the required ports (typically ‘all open’ when dealing with a non-secure game server).

ISA Server Inbound Request Listener

The ISA Server listens to incoming web requests on what is called the inbound request Listener. By default, the inbound web request Listener uses port 80 on the external interface of the ISA Server. You can change this if you like, but then everyone that needs to connect to your web site will have to include the port number is their request. If you want to make your site easy to access, don’t change the default port number setting. Note that the requests accepted by the Inbound Request Listener are intercepted by the Web Proxy Service.

You will have to add the inbound Listener for the IP address(es) that you want the ISA Server to listen on.

1. Open the ISA Server management console, expand the Servers and Arrays node, and then right click on your server. If you are running an array, right click on the array name. Then click the Properties command. In the dialog box that appears, click the Incoming Web Requests tab. You will see something like what appears below.

   

2. On the Incoming Web Requests page you make the configuration changes required for your inbound web request Listener. Note that you have two options, one is the Use the same listener configuration for all IP addresses and the second is Configure listeners individually per IP address. If you have multiple IP addresses bound to the external interface you should configure the Listeners separately. I like to configure the Listeners separately even if I have a single IP address, because I have a better idea of what’s going on that way.
3. Select the Configure listeners individually per IP addresses and then click the Add button. That brings up Add/Edit Listeners dialog box. A completed configuration appears in the figure below

   

4. In the Server drop-down list box, select the name of the server. In the IP Address drop-down list box, select the IP address on the external interface that you want configured as a Listener. If you have multiple IP addresses bound to the external interface, you’ll have several to choose from. Those that have already been configured as Listeners won’t be available. You can configure an optional Display name to describe the Listener. The entries in the Authentication from allow you to configure authentication options if you wish users to authenticate against the ISA Server. Note that these options to not configure the authentication options available to authenticate against the web site. These options are for the ISA Server only. Note that configuring the options here does not automatically require authentication against the ISA Server; these options just make the various authentication types available if you decide to enable authentication.
5. Click OK, and you’ll see something like what appears below.

   

6. The new Listener appears in the box containing all the configured Listeners. In the TCP Port box you can change the port number used by the Listeners. Note that this setting applies to all Listeners, not just the one you have selected in the box above. You cannot use a different Listener port number for each specific Listener; this setting is a global one. If you want to require that users are authenticated before accessing any internal web site, put a checkmark in the checkbox for Ask unauthenticated users for identification. Note that this is also a global option and cannot be configured on a per Listener basis.
7. Click Apply and you will see the ISA Server Warning text box as pictured below.

   

8. If you want the ISA Server to restart the service, choose the Save the changes and restart the service(s) option. If you want to restart the service yourself, choose the Save the changes, but don’t restart the services(s) option. I like to select the latter option because when you let the ISA Server do it for you, it might take awhile before the server actually gets around to doing it. When you do it yourself, you know exactly when the service is restarted.

Conclusion

You can publish services located on your internal network using the publishing wizards included with ISA Server. This includes a special publishing wizard that is dedicated to publishing web sites on the internal network. The wizard makes it easy to publish these internal web sites. However, there is some footwork you need to take care of before actually publishing the site. In this article we covered some of the key preparatory elements that need to be completed before publishing your web site.

In the second part of this two part series on web publishing, we’ll go over the actual steps you perform when publishing a web site, and examine some of the standard and non-standard procedures you can carry out to publish your site. See you then!