(NOTE: This is pre-release information and I am aware of a couple of improvments in the final release of the Service Pack that weren’t included in the pre-release version. I will update this article and put a blog post on the front page of this site so that you’ll know when the updated version of this article appears. Thanks! –Tom.)
In the first part of this series on ISA 2006 Service Pack 1 we looked at the Change Tracking features and the Test button feature that you can use with Web Publishing Rules. In this article we will continue our exploration of ISA 2006 SP1 features by delving into two very cool and useful features–the Traffic Simulator and the enhanced Diagnostic Viewer.
If you missed the first part in this article series please read Your New ISA Firewall: ISA 2006 Service Pack 1 (Part 1)
Traffic Simulator
When you click on the Troubleshooting node in the left pane of the ISA firewall console, you’ll notice a new tab – the Traffic Simulator tab. The traffic simulator can help you troubleshoot your access and publishing rules by simulating the traffic you are having problems with and then comparing that simulated traffic to your current rule set.
When you click on the Traffic Simulator tab, you’ll see that you can test for four specific scenarios:
- Web Access This tests connection problems related to outbound access through the ISA firewall’s Web Proxy filter
- Non-Web access This tests connection problems related to outbound access for protocols that do not go through the ISA firewall’s Web Proxy filter
- Web publishing This tests connection problems related to Web Publishing Rules.
- Server publishing This test connection problems related to Server Publishing Rules
Let’s take a look at each of these scenarios to see what parameters are available for each of the scenarios.
Start by selecting the Web access scenario. After selecting this scenario you have several options in the Source Parameters frame. These include:
- IP address This is the IP address of the host behind the ISA firewall that’s experiencing the problem
- Port (* for all) This is the source port for the host behind the ISA firewall that’s experiencing the connection problem. In most cases you won’t need to specify a source port. However, if you have rules and protocols that designate source port requirements, you might want to take advantage of this option.
- Traffic sent from anonymous user Select this option if the client having the outbound Web access problem should be able to connect to the destination anonymously.
- Traffic sent from this user Use this option if the client having the outbound Web access problem needs to authenticate before getting outbound access to the destination Web server
In the Destination Parameters frame you enter the URL of the site that the client is having problems accessing.
In this example, we’ll test to see if a client on the internal network behind the ISA firewall at IP address 10.0.0.2 can connect to the www.isaserver.org Web site. Since I also expect clients to be able to authenticate, I’ll enter the user name Administrator.
I then click the Start button to run the test. At the bottom of the figure below you can see that the traffic was allowed by an access rule name Allow HTTP.
Figure 1
Let’s try another test. In this example we’ll use the same client IP address located behind the ISA firewall. But this time we’ll change the scenario so that we can test a non-Web protocol. Non-Web protocols do not go through the ISA firewall’s Web Proxy filter and are handled only by the firewall service and application filters.
I’ll set the test so that traffic should be allowed from an anonymous user to the destination IP address 192.150.87.2 at UDP port 53. I’m testing is to see if the client behind the ISA firewall can make DNS queries to a specific DNS server.
But before I test, take a note of the Apply diagnostic logging to simulated traffic checkbox. We want to put a checkmark in that checkbox so that if the test fails, we can check the details of the connection in the diagnostic logging viewer.
This time after clicking the Start button we see that results aren’t quite as happy as they were for our first test. This time the traffic was denied. However, the information provided isn’t very helpful. All it says is that the traffic went from internal to external, that there was a Network Rule that connected the client to the server, that the protocol was recognized as DNS and that no application filter applied to the rule. However, it does say that the rule that denied the connection was the “All Open” rule, so that might be helpful when we look closer.
Since this information doesn’t really provide us enough information to solve the problem, we will need to dig deeper and look at the diagnostic logging information to see if that can solve the problem.
Click the View Log button to see the simulated traffic.
Figure 2
Aha! That was almost too easy. Here we can see that the rule “All Open” which I had expected would allow the traffic, did not allow the traffic because The rule does not match because the rule requires authentication and no user is specified in the packet and The rule All Open requires user authentication. You can also see further down that all other aspects of the connection attempt were fine and that the only problem was with the lack of authentication. Thus, in order to allow the DNS connection to the destination server, I need to install the Firewall client on the DNS server making the outbound request (not recommended) or create another rule that allows the DNS server making the outbound DNS query anonymous access to DNS servers on the Internet (recommended).
What is quite nice about the traffic simulator and its integration with the enhanced diagnostic logging feature is that you see only the traffic generated by the traffic simulator. You don’t have to weed through diagnostic logging trying to find which connection is of interest. However, even if we have to look at actual network traffic, we’ll find that it isn’t that hard to find the information of interest.
Figure 3
Figure 4
However, the Traffic Simulator with diagnostic logging does have some limitations that can’t solve all configuration problems. For example, I’ll select the Web Publishing scenario from the list. Then I’ll enter the source IP address of 192.168.1.70 which is located on the external network for this ISA firewall. Since the Web Publishing Rule requires authentication, I’ll enter Administrator as the user who wants to authenticate to the Web Publishing Rule. Finally, I’ll enter the URL of http://ssl.msfirewall.org and make sure that the ISA firewall resolves ssl.msfirewall.org to the IP address on the external interface of the ISA firewall that the Web Listener is using to listen for connection for this rule.
If you recall from part one of the article series, we created a Web Publishing Rule that didn’t work. There were two reasons why it didn’t work:
- First, the Public Name didn’t match the common/subject name on the certificate bound to the Web Listener. The Test button failed to find the problem. However, the Web Publishing Rule wizard did identify the problem and called it out with a big yellow exclamation mark. So, in practice, there would be no need for the Test button to find this problem since you would have corrected it before getting to the end of the Web Publishing Rule wizard
- Second, the name on the To tab didn’t match the common/subject name on the Web site certificate that was bound to the published Web site. We fixed that problem by checking the common/subject name on the Web site certificate and then changed the name on the To tab to match that name.
So, this rule should still fail, right? Let’s click the Start button and see what happens. The traffic simulator says that the traffic is allowed. That’s funny, because it shouldn’t be allowed, since we have a certificate name mismatch.
Let’s click the View Log button. Maybe diagnostic logging has detected a problem that didn’t show up in the Traffic simulator.
Figure 5
Nope, doesn’t seem to be anything wrong here. It says right here that The rule Secure Web Site matches the packet. The packet is allowed.
So it seems that the Traffic Simulator was fooled too, just like the Test button. However, this is not to say that ISA didn’t let us know that there was a problem early on – the New Web Publishing Rule Wizard warned us that there was a problem with the rule.
And to be fair, the connection is allowed by the rule. Just because there is a certificate name mismatch between the Public Name on the Web Publishing Rule and the common/subject name on the listener does not mean that the connection will not be allowed. What it means is that the client browser will receive an error when it tries to connect, but if the user ignores the error, the connection will still succeed. However, if the user is using a non-browser client, such as the Outlook RPC/HTTP client, then there is no warning dialog box and the connection will fail (at least in previous versions of Outlook – I believe that the Outlook 2007 RPC/HTTP does provide a mechanism for you to click through the error).
Given this, I say that the Traffic Simulator wasn’t fooled after all. Connections to the secure Web site are allowed, and if there are any problems, they would be on the client side.
Figure 6
Let do one more test of the Traffic Simulator. In this case we’ll select the Server Publishing scenario. I’ll enter the IP address 192.168.1.70 as the source IP address, which is an external IP address for this ISA firewall. For the destination I’ll enter the IP address of a server on the internal network behind the ISA firewall – 10.0.0.2. The destination protocol will be TCP and the destination port will be 25. This example tests to see if inbound SMTP connection can be made to 10.0.0.2.
I click the Start button and the test results show that the traffic is denied by the default rule. Let’s click on the View Log button and see if the enhanced diagnostic logging has anything interesting that can confirm why inbound SMTP to TCP 25 on 10.0.0.2 was denied.
Figure 7
Looking at the enhanced diagnostic logging file, we see that the ISA firewall checks system policy rules and other firewall rules. You will see a line that says The rule Default rule blocked the packet. This suggests that there is no rule to allow the packet. When I go back to the firewall policy on this machine, I find out that indeed, there is no Server Publishing Rule allowing inbound SMTP to 10.0.0.2. Diagnostic logging saves the day again!
Figure 8
Diagnostic Logging Improvements
To this point you’ve seen that the new diagnostic logging improvements are tightly integrated with the Traffic Simulator. Using diagnostic logging with the traffic simulator is very nice, because you’re looking at pure traffic and don’t need to weed out extraneous traffic. However, sometimes you need to take a look at traffic moving over a life network with hundreds of machines connecting inbound and outbound through the ISA firewall. In that case, you need some help to separate the forest from the trees.
To solve this problem, the new Diagnostic Logging tab in the Troubleshooting node in the ISA firewall console allows you to use an easy to use filter to find the information you’re interested in. Let’s look at some examples.
First, before you can make use of the diagnostic logging feature, you need to turn on diagnostic logging before you repro the problem. Click on the Tasks tab in the Task Pane while in the Troubleshooting node. You have two options here. One is the Enable Diagnostic Logging and the other is to Delete Diagnostic Log. You need to enable logging before the repro. After you’ve done your repro of the problem, the link will change to Disable Diagnostic Logging, which you should click after the repro is complete.
Figure 9
After completing the repro, go back to the ISA firewall console and enter some filtering criteria that will help you find something in the log file that will get you closer to solving the problem. In this example, one of our users is having problems connecting to www.bluecoat.com. Our user needs to connect to that site to do research on the Blue Coat feature set.
There are two ways we can set the filter:
- Message contains This is anything in the message that might be included in the log. Example might be source IP address, destination IP address, destination URL, protocol name, and others.
- Context contains allows you to filter for strings in the context. Each communication attempt through the ISA firewall will be associated with a specific context, that allows you to see what the ISA firewall does with that specific communication. You might have noticed that when we were looking at the Traffic Simulator and the diagnostic logging for the simulated traffic, there was a context column that had the same context value for all the entries. That’s because we were looking at one specific communication attempt.
Let’s say that I’m not sure what I’m looking for, but I suspect that the message will contain www.bluecoat.com. In this case, I’ll enter www.bluecoat.com in the message contains text box and then click the Apply Filter button.
Bam! I got lucky. It appears that there is a communication in the log file that has this string included in it. You’ll notice that both entries have the same value in the context column. Let’s take advantage of that information.
Figure 10
Remember that you are searching for strings, so you don’t have to enter the entire value if you are confident that you have a unique string. Looking at the context value, I’m going to guess that there aren’t any other contexts that have the c15 string. I might be wrong; if so, I’ll look for another context string that is more unique.
I’ll enter c15 in the Context contains text box and click Apply Filter.
Figure 11
The log view now displays all the records that have the correct context (I cut out the context column in the graphic so that you could see the records more clearly). Now that we have all the information related to a connection that had www.bluecoat.com in the message, let’s see what we can find out.
In reading the log file you can see that there is an access rule that denied the connection. The name of the Access Rule is Deny Bluecoat. Now I know that I have such a rule in my firewall policy and can change the rule to allow access, or create a new rule that allows only a specific analyst access to the www.bluecoat.com site.
Figure 12
Let’s look at another example. I’m having problem pinging an external client from a client on the default Internet ISA firewall Network. First thing it to enable diagnostic logging and start pinging that external client from the client on the default Internal ISA firewall Network. After reproducing the problem, I turn off diagnostic logging and enter ping in the Message contains text box and click Apply Filter.
Figure 13
Looks like there are a couple of contexts that include ping in them. Let’s enter the string 5949 in the Context contains text box and click Apply Filter to see the details of one of these communications.
Figure 14
Figure 15
You can see an entry that says Protocol: PING. Moving down from that line you’ll end up at the entry that I’ve highlighted that says The rule does not match because the rule requires authentication and no user is specified in the packet. There is also identification of the rule in the entry that states The rule All Open requires user authentication.
Yay! The diagnostic logging feature saved the day again. Now I know that I need to remove authentication requirements for the All Open rule, or create a new rule that allows anonymous access to outbound PING requests.
Figure 16
Now let’s do one more test. My internal clients are having problems sending outbound SMTP messages to their Internet SMTP server. First, enable diagnostic logging, repro the problem, and then disable diagnostic logging.
Good to the Filter Criteria section and enter smtp in the Message Contains text box. Since this is an SMTP problem, there’s a good chance that “smtp” is going to show up in the messages for the connection attempt for outbound SMTP.
Figure 17
The filter showed a number of SMTP entries with different context IDs. Instead of going back into the Filter Criteria section again, what you can do a click on the context ID in the Context Column and it will take you to all the entries with that context ID, as you can see in the figure below.
Looks like our SMTP problem is similar to our ping problem. If you read through the entries for this communication attempt, you can see that the All Open rule requires authentication and the SMTP connection from the client wasn’t able to send authentication information to the ISA firewall. In order to solve this problem, we’ll need to install the Firewall client on the client computer so that we can authenticate outbound SMTP connections.
Figure 18
Summary
In this, part 2 of our two part article series on ISA 2006 Service Pack 1, we took a deep dive into the Traffic Simulator and Diagnostic Logging features. We saw that we could use the Traffic Simulator to try and repro connectivity issues, and then use the tightly integrated diagnostic logging feature to drill down on the details of the connectivity problem. We next took a closer look at the diagnostic logging feature and saw how you can use the filtering feature to find problematic traffic even on a live, busy network. Included in the discussion were troubleshooting examples that should help you understand how these features work and enable you to put them into use on your production networks. Thanks! –Tom.
If you missed the first part in this article series please read Your New ISA Firewall: ISA 2006 Service Pack 1 (Part 1)
