I spent most of today trying to get some ISA Server 2000 web proxy clients to access a web application using HTTPS on a non-standard port (4443). The issue was further complicated by the fact that the application server needed to be accessed using an upstream proxy server. Once the network manager had verified that the upstream proxy could access HTTPS requests on 4443 (and I had tested using my browser and the upstream proxy settings), it took me a while to work out why ISA Server wasn’t forwarding the requests. Instead, my proxy logs were showing some strange results:
sourceip anonymous Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 15:13:13 isaservername – targetserver – 4443 – 212 2855 SSL-tunnel CONNECT – – 407
sourceip anonymous Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 15:13:13 isaservername – targetserver – 4443 – 316 537 SSL-tunnel CONNECT – – 407
sourceip domainname\username Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 15:13:13 isaservername – targetserver – 4443 – – – SSL-tunnel – targetserver:4443 Inet 12204
Because the logs suggested that the ISA server was forwarding requests to the Internet, I thought that I needed to set up another destination set for the application server and a separate routing rule for access to this server using the non-standard port number. That turned out to be completely wrong (and I’ve since removed both the new destination set and the routing rule). I still don’t know why the 407 errors occur (HTTP client error 407 means proxy authentication required) but the 12204 error led me to the answer, which is contained in Microsoft knowledge base article 283284.
“With secure socket layer (SSL) tunneling, a client can establish a tunnel through ISA Server directly to the web server by using the requested HTTPS object. Whenever a client browser requests an HTTPS object through ISA Server, it uses SSL tunneling. SSL tunneling works by default for outgoing client requests to ports 443 and 563.”
The article also includes the VBScript code to add a port to the ISA Server’s tunnel port range. Depending on the version of ISA Server in use, this information is stored in a different location:
- For ISA Server 2000 Standard Edition, ISA Server 2000 Enterprise Edition (standalone mode), and ISA Server 2004 Standard Edition: ISA storage is maintained in the registry.
- For ISA Server 2000 Enterprise Edition (array mode): ISA Storage is maintained in Active Directory.
- For ISA Server 2004 Enterprise Edition: ISA Storage is maintained in the Active Directory application mode (ADAM) configuration storage server).
Although the code to do this is contained within the Microsoft article, Jim Harrison has made the script available for download from his ISA Server tools repository. Once I had edited the script to change the port number to 4443, I ran it on one of the array members and force refreshed the settings by selecting the array in the ISA Management console and pressing F5. What none of the newsgroup information I found on this topic told me (although to be fair the Microsoft article says that a restart of the Microsoft ISA Server Control service is required) is that it also didn’t take effect until I restarted the web proxy service on my ISA Servers. Another item to note from the Microsoft article is that the script does not produce any output if it succeeds and if it is run again, it will produce an error because the range being set already exists.
Once I had restarted the web proxy service, my clients could access the web application using port 4443 and the ISA Server logs showed a successful connection via the upstream proxy server:
sourceip domainname\username Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 16:56:01 isaservername – upstreamproxyname upstreamproxyip upstreamproxyport – 726 2258 SSL-tunnel – targetserver:4443 Upstream 995
Yesterday, I stumbled across AuditMyPC, which includes a number of tests (and tips) to help improve PC and network security. Most of the information is available elsewhere on the ‘net but it’s nice to find it all in one place. What worried me (and convinced me that the guy who runs this site knows what he is doing) is that the site was able to discover my NATted IP address. Luckily it was only on my PC with the Microsoft Java Virtual Machine (JVM) installed (unfortunately I need the JVM to use my employer’s awful time-sheeting system and, being a consultancy, time-sheeting is pretty important to us!). I know that my public IP address is easily obtained, but the ease at which a bit of Java code discovered information which should only be available from inside my firewall was a bit of a worry, especially on a fully patched Windows Server 2003 (SP1) system!