It was supposed to be so easy. The new server was already built, with the same IP addresses as the old one. All I had to do was disconnect the NT 4.0 Proxy Server from the network and power on the new Windows Server 2003 R2 box with Internet Security and Acceleration (ISA) Server 2004 on it, then configure and test a few filter rules; but I had forgotten the first law of IT consultancy – nothing is ever straightforward – which is why I’m writing this post on the train to work after rolling back the migration and getting just 4 and a half hours sleep last night…
Firstly, I decided that the ISA Server should be joined to the Active Directory. My original plan had been that leaving it in a workgroup would be secure, but as I didn’t want to allow unrestricted anonymous (i.e. unmonitored) Internet access I’d be limited with my authentication options (either set up a RADIUS server to handle authentication or mirror the user accounts on the ISA Server). I wasn’t confident that ISA Server would work well if it was joined a domain after installation so I uninstalled ISA Server, joined the computer to the domain, and reinstalled ISA Server, plus service pack 2 and other updates.
It only took a few seconds to configure the cache and set up a firewall policy rule to allow all ports outbound access (just as a test, I could lock it down again later), add all the internal networks and enable the web proxy client, following which Internet access from the local network was restored. The trouble was that none of the machines on remote sites could access the Internet.
Suspecting a DNS issue, I began to investigate name resolution problems and (here was my mistake) questioning why no forwarders were configured on the internal DNS server (because DNS monitoring showed that the simple queries were fine, but recursive lookups were failing). If I’d been thinking clearly, I would have realised that the internal network doesn’t need to have a recursive DNS path to the ISP’s DNS servers (the proxy server should handle that on behalf of the clients) – although I do think that having a clear path from clients to the internal DNS and onwards to the ISP’s DNS is the most straightforward configuration, supporting both internal (Active Directory) and external (Internet) name resolution (and Microsoft’s advice is to configure only internal or external DNS on the ISA Server – not both).
The problem was the network configuration on the ISA server. Jim Harrison’s excellent article on configuring ISA Server interface settings is my bible when configuring the network cards on an ISA server, but I hadn’t set up the routes from the external network to my internal networks correctly. The local LAN was fine, but ISA Server was rejecting requests from remote internal networks because it didn’t understand the underlying network path (flagging a configuration error alert warning that the address range of an ISA Server network should match the address ranges routable through the associated network adapter as defined in the routing table). When I monitored the traffic flow, I could see incoming requests that were denied with no rule was given as the reason – another clue that there was a problem with the network rules.
Although the configuring ISA Server interface settings article points out that a route will be required to each internal network, I’d set the next hop as the internal interface of the ISA server, rather that the local router (the internal NIC doesn’t have a default gateway if configured correctly). Adding persistent routes for each of the internal networks (
route -p add remoteinternalnetwork mask subnetmask routeripaddress) fixed the issue, after which
nslookup (and web access) began to work from all sites.
Unfortunately, by the time I’d worked this out, it was too late to set up and test the various filter rules that are needed to ensure correct (authenticated) HTTP(S) and FTP browsing, SMTP e-mail, access to OWA, etc., so I decided to back out and reconnect the legacy proxy server. At least now I know that the connectivity problems are resolved, I can attempt the migration again another evening.