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.
Hi Mark
I’ve been working with ISA and proxy since early proxy 2.0 days and had a 5 year stint working with Microsoft.
The trick with ISA 2004 is to think of it as a piece of your network infrastructure and not just a proxy server. ISA 2004 is a common criteria EAL4+ certified firewall, VPN and proxy server which is a far cry from what old Proxy 2.0 ever was. If you think of deploying ISA the same way as you would think of deploying any other firewall or even a router, the proxy side of it is simple – in fact, its automatic! This is true of the Network configuration in ISA and the Windows routing table. If an internal network hasn’t had all the internal IP addressed added to it and ISA sees a packet arriving on that interface from an IP address that hasn’t been correctly configured, ISA will deny the packet as it will see it as a possible IP spoof (an External packet arriving on the Internal NIC). Thus its key to get this bit right and you can’t switch it off, its the way the product has been designed.
Regarding the domain membership. I always recommending joining an ISA Server 2004 box to the domain, even if it is a firewall! There is a huge fear about domain joined machines accessing the Internet but this is an unfortunate NT4 legacy way of thinking. Windows security has come a LONG WAY since then and it is actually more secure to add the machine to the domain. You can then make use of kerberos authentication to the AD and group policy to lock down the security of the ISA box its self. A workgroup has no authentication context to work in and thus you end up having to allow dreaded anonymous traffic around the edge of the network.
It is also perfectly ok to join an ISA Server box to a domain AFTER ISA has been installed. This is exactly how ISA Server based appliances are deployed on a regular basis.
Steven Hope
Vircom Ltd
steven@vircom.co.uk
http://www.vircom.co.uk/
Hi Steven,
Thanks for the comments – you make some interesting points. I’ve previously commented on this blog about ISA Server’s EAL4+ certification and you are right to point out that it is a very capable firewall (in fact one of the few that perform application-layer filtering); however in this case I really was installing it simply to replace a Proxy Server 2.0 installation (at least that’s the initial intention – I’m sure the requirement will grow later).
The network issues were entirely down to me not reading Jim Harrison’s guide to configuring ISA Server interface settings properly – I just hope that by blogging them here I might help some other pour soul with the same problem!
It’s especially interesting to read your comment about joining the domain post-installation. What you say about joining ISA Server appliances to a domain makes sense but my source was a Microsoft TechNet ISA Server 2004 setup troubleshooting article, which says “Domain and workgroup membership should not be changed after you install ISA Server. Otherwise, ISA Server is no longer functional.” – I guess Microsoft get it wrong sometimes too!
Thanks again for getting in touch – I appreciate the advice (especially as tomorrow night I’ll be going back to retry the migration).
Mark
Recently have two projects that need to re-configure IP addresses on already-installed ISA servers (2006 EE). Both got quite big barrier in IP routing due to the NIC ordering (not just binding order).
IP routing is quite a big stuff need to thoroughly understand Windows routing before install ISA server, but how about change IPs after your ISA has been running well for some time? Will Windows re-generate routing table automatically? or ISA will do it? How about a reboot? Right after the change, will routing table change itself or need a reboot?
Another question is how would routing apply to NIC if there are two NICs routable to the same segment? Will it use the ordering in NIC/Advanced settings, or in registry, or elsewhere? This question raised because recently I need to use the IF to force using a physical NIC, but after reboot, it applied to another NIC in same segment. MS suggests to use RRAS to configure NIC or check the orders in registry.
Not fully convinced though.