Weird ISA error, and apparent solution

This morning when I tried to use FrontPage (don't even start) to edit one of my web sites, I was faced with this error:

Error Code: 500 Internal Server Error. Internet Control Message Protocol (ICMP) network is unreachable. For more information about this event, see ISA Server Help. (10051)

10051 means "System Call Interrupted." That was not all that helpful though. What system call? And, what does ICMP have to do with it?

To understand the problem, we need to consider the network design. I have an ISA 2004 server, sitting on the same system (running Windows Small Business Server 2003 Premium) as the web sites. Therein lay the rub. The ISA dashboard kind of gave it away actually. There were several alerts there saying that ISA could not bind to port 80 on 192.168.0.1, in other words, the inside network interface. Now, IIS should already be bound there, so that makes some amount of sense, although given the choice of IIS and ISA, I think I would prefer if ISA got to bind to the interfaces first. The more I use ISA the more I like the logging and alerting infrastructure.

The problem turned out to be the ISA Web Proxy Auto Discovery (WPAD) information. Somehow, and I swear it had nothing to do with me, ISA was set up to serve WPAD from port 80, instead of the default of 8080. Of course, IIS was already bound there, so hence the error. That seemed to bring down the whole proxy. and cause the connectivity problems.

I was able to find a number of people with the same problem, but not anyone who had figured out the solution, so I thought it made sense to post it. The solution was to change the port that ISA serves WPAD on back to 8080. Go to the ISA console, expand "Configuration", click on Networks, and double-click the "Internal" network. Go to the Auto Discovery tab and set it to 8080, which is where the firewall clients will look for it anyway unless you tell them otherwise.

While I was at it, I set up the split DNS and direct access to the web sites from the internal network as well, in accordance with Tom Shinder's advice. I really think this solution is rather inelegant, and a lot of extra work for something that should be automatic. I also worry that external connectivity problems will go overlooked this way, but still. We'll see. I reconfigure this thing whenever I have time, so I'll use it this way for a while.

Update Dec. 23, 2005

OK, so I decided to turn off the "split DNS" feature. If there are any problems accessing a site from the outside you will not see them if you use that feature. For pure troubleshooting reasons, it makes sense to see the site as close to how outsiders do as possible.