Yuri Diogenes published a very nice article on a problem one of his customers had with publishing a Web Server, with the Test button not indicating what the problem was. You can read this article over at https://blogs.technet.com/isablog/archive/2008/07/10/isa-server-2006-sp1-problems-that-goes-beyond-the-test-button.aspx
Yuri and the team did a great job showing the network monitor traces of the problem. However, you really didn’t need to use NetMon to figure out the problem. Here’s why.
When you use the Test button, you’re testing connectivity from the ISA firewall’s internal interface to the IP address of the Web server. If the Test button shows that things are OK, then you know there is an intact request/response path between the ISA firewall’s internal interface and the published Web server.
But what about the situation where can external client is able to connect to the published Web server, but the published Web server is not able to return a response. This indicates a broken request/response path, with the broken part being the response path.
Now think about what could cause a broken response path. We know that there isn’t a physical layer problem, since the request path was intact. Thus, there must be a software configuration error or issue somewhere.
We know that the request/response path was intact from the ISA firewall’s internal interface to the published server. And by default, Web Publishing Rule replace the source IP address in the external client request with the IP address of the ISA firewall’s internal interface.
However, many ISA firewall admins will configure the Web Publishing Rule to preserve the source client IP address. In that case, the source IP address the Web server sees is the public address of the requesting client. That means that the Web server will need to be able to have a route to the Internet that passes through the ISA firewall. In many cases, that default route isn’t through the ISA firewall, as the default gateway on the Web server may be another IP address, or interposed routers on the corporate network might be using another IP address as their route of last resort.
You could also use ping to confirm this issue — no reason to muddy the water with HTTP requests. In fact, network monitor would not even be required to solve this problem, as you would see the external client requests in the Web server’s log files and you would not see the responses reach the client. However, NetMon would have been useful in that you would not see the responses reach the ISA firewall, even though the request made it to the Web server.
Yuri’s article is a nice reminder that you need to remember your basic TCP/IP when working the ISA firewall. The ISA firewall is a network device, a piece of your network gear, and you need to treat it that way.
HTH,
Tom
Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP — Microsoft Firewalls (ISA)