In our first article on troubleshooting the Windows XP firewall, I explained how to configure your customer's firewall when Windows locks you out. Sometimes, however, you may find that although you have configured a particular firewall-related setting, Windows continues to use the default settings. Windows XP firewall settings are stored in a number of locations, and some of these settings take precedence over others. The key to solving any Windows firewall-related problem is to figure out where the problematic settings are stored. Fortunately, there are a number of tools that you can use to diagnose the problem. Let's take a look at the command-line utility Netsh.
I like to begin the troubleshooting process by opening a command prompt window and entering the following command:
Netsh firewall show state verbose=enable
As you can see in Figure A, this command provides you with lots of information about how the firewall is enabled. From an initial troubleshooting standpoint, I tend to think that the information in the Firewall Status section (at the top of the figure) is the most useful.
Figure A The Netsh command provides lots of diagnostic information.
The Firewall Status section provides the information shown below:
Firewall status:
------------------------------------------------------------------
Profile = Domain
Operational mode = Enable
Exception mode = Enable
Multicast/broadcast response mode = Enable
Notification mode = Enable
Group policy version = None
Remote admin mode = Disable
Scope: *
As you can see, the Profile is set to Domain. This line always indicates whether the profile is running in Domain Mode or Standard Mode. If a group policy is in use, then this information will allow you to isolate the firewall settings to a particular branch of the group policy settings tree.
The Profile line, however, doesn't give you all the information you need. It's also important to look at the Group Policy Version line. In this particular case, the Group Policy Version is set to None. This means that no firewall-related group policy settings exist and that the computer is only using local firewall settings.
For a more complete picture of where the firewall settings are coming from, cross-reference the Profile and the Group Policy Version. The table below shows what the various combinations mean:
| Profile |
Group Policy Version |
Meaning |
| Standard |
None |
The computer is using only local Windows firewall settings. |
| Standard |
Windows Firewall |
A local group policy setting contains Windows firewall-related settings. |
| Domain |
None |
The computer is logged into a domain, but no firewall-related group policy settings exist. |
| Domain |
Legacy Firewall |
The computer is logged into a domain, but a group policy setting is actually blocking the use of the Windows firewall. In this situation, navigate through the group policy settings tree to Computer Configuration | Administrative Templates | Network | Network Connections, and disable the "Prohibit Use of Internet Connection Firewall on Your DNS Domain" setting. |
| Domain |
Windows Firewall |
The computer is logged into a domain, and Windows firewall-related group policy settings exist. |
Although the Firewall Status section is the most interesting, there is other valuable information that you can obtain through the Netsh command. If you look at Figure A, you can see that the majority of the text on the screen is related to firewall exceptions. This provides you with a definitive way of knowing which firewall ports are open and by what application. For example, the command differentiates between a program exception and a port exception. This is important, because the Windows firewall configuration interface uses different methods for adding a program exception and adding a port exception, as shown in Figure B. Knowing whether an exception is program- or port-related can help you to more easily find the incorrect setting. It is also important to point out that exceptions can also be defined through group policy settings.
Figure B Windows treats program and port exceptions differently.
The other interesting piece of information that the Netsh command provides you with is the location of the firewall log. In Figure A, we can see that the log is located in the C:\windows directory in a file named PFIREWALL.LOG. This log file can help you to diagnose firewall problems, but it's important to understand that the file may not always exist, even if Netsh says that it does. I was unable to find any definitive information on the subject, but it seems that only certain types of activity are logged, and if no loggable activity has occurred, then the log file is not created.
Conclusion
In this article, I explained some techniques you can use to help you determine where specific firewall-related settings originate from. In part three of our series on troubleshooting the Windows XP firewall, I continue the discussion by showing you how to audit firewall activity.
About the author
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
