One of the new features in ISA Server 2004 is the concept of multi-networking. You can use the multi-networking features of ISA Server to protect your network against internal and external security threats, by limiting communication between clients, even within your own organization. That’s indeed a great feature but consider for a moment the following simple but very common scenario:
On the ISA internal interface we have enabled the publishing of the automatic discovery information so we can use automatic discovery (WPAD in DNS or DHCP) to allow Firewall clients and Web Proxy clients to automatically locate the ISA Server computer. That works all well for the internal clients and everybody is happy.
On the perimeter network we have a number of Windows hosts. It would be great if we could keep them up-to-date by using Windows Update. However, if you try Windows Update as a SecureNAT client it won’t work that well because at some point an SSL connection is setted up. This request is obviously made by IP address. As a result, ISA must perform a reverse DNS lookup in order to match the request to a Domain Name or URL set. Yet, this will not succeed because no proper reverse DNS entries exists for the Windows Update sites.
So, if we want to restrict the allowed HTTP/HTTPS communications originating from the perimeter hosts than we will have to configure those hosts as Web Proxy clients. To accomplish that we enabled the Web Proxy outbound listener and the publishing of the automatic discovery information on the ISA perimeter network. Next, we configured a WPAD entry in the DNS zone ‘splab.net’ pointing to the ISA perimeter interface (isa.splab.net). At last we checked out that ‘Automatically detect settings’ was enabled in IE (default setting) on the perimeter hosts. Despite all this effort it still didn’t work. Why?
If you take a closer look at the ‘wpad.dat’ file returned by the ISA server to a host located on the internal and the perimeter network, you will see that the functions MakeIPs() and MakeNames() are multi-networking aware; that means they return network specific information. However, the function MakeProxies() returns always as proxy server the FQDN based on the machine’s domain association, regardless of the network where this data is sent. In our case the FQDN is ‘isa.intranet.splab.net’:
According to my resources, this is by design with no plans to change this for the current ISA version but will be considered in future releases. In other words, with ISA Server 2004 the perimeter hosts are instructed to use the Web Proxy listener on the internal interface instead of the perimeter one. Of course this will not work because there is no default rule allowing that type of access.
The proper way to solve that problem is to make sure that internal hosts resolve the returned FQDN (in our case ‘isa.intranet.splab.net’) to the primary IP address assigned to the ISA internal interface (in our case ‘192.168.22.1’) and that the perimeter hosts resolve the returned FQDN (in our case ‘isa.intranet.splab.net’) to the primary IP address assigned to the ISA perimeter interface (in our case ‘192.168.33.1’). How you accomplish that depends on your specific DNS infrastructure, but in our case we use an internal DNS server responsible for the domain ‘intranet.splab.net’ and defined there two forward and reverse resource records for the FQDN ‘isa.intranet.splab.net’:
Now, to be sure that the proper DNS answer is returned to the host depending on the location of the host, you must also make sure that the option Enable netmask ordering is enabled in the properties of your DNS server as shown in the figure below:
For more information about the DNS Netmask Ordering feature, check out the Microsoft Technet article How DNS Works and the Knowledge Base article Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS. Take note that I tested the above instructions only in an ISA Server 2004 SE scenario. Personally, I have no experience with ISA Server 2004 EE but I expect that as long as you have an FQDN in the MakeProxies() function or whatever the function is called in an enterprise edition, you can apply the same logic.
HTH,
Stefaan