Remember the Basics of TCP/IP When Publishing Web Servers
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/...n.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: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)
Yuri Diogenes Says:
July 13th, 2008 at 11:01 am
Hi Tom,
Good points about the behavior. When we went to the netmon path was also to show the reader how things work behind the scenes. As you said sometimes customers overlook the basic TCP/IP functionality and showing the netmon is a good way to remind them the basics.
The other point that it is also good to share about using netmon in such scenario is: sometimes you are on a conf call with the ISA Admin, the Networking guy and you try to explain why is failing without showing the netmon. The Networking guy sometimes swears that there a route and it should be working just fine since the devices that he administers are “well configured”. At that point our friend netmon is a good way to proof the point. This happens a lot in PSS since we have to deal with multiple teams in the customer side.
Thanks for your comments and clarification about the behavior.
Yuri Diogenes
Thomas Shinder Says:
July 13th, 2008 at 11:04 am
Hi Yuri,
Excellent points! I didn’t even consider the value of netmon in a “political” situation. I agree that it would be very useful to have those traces in such circumstances.
Thanks!
Tom