Windows Firewall Basics
By Mark Minasi
Mark Minasi is a best-selling author, commentator and all-around alpha geek. He is best known for his books in the Mastering Windows series. The following excerpt is from chapter eight of Minasi's newest book, Mastering Windows Server 2003 Upgrade Edition for SP1 and R2, entitled "Windows Firewall Basics." Read the entire chapter here.
When Windows Firewall first appeared in XP SP2, I started getting odd questions on email. They all went something like, "Hey, something's weird on my system now that I'm running SP2. I've got two computers, A and B. A can ping B, but B can't ping A. What's going on?" What was going on was that system A was running XP SP2 with Windows Firewall enabled by default, and system B was a Windows 2000 system without any firewalls.
When A pinged B, then the firewall on A said, "Ah, we're pinging B; when the response comes back, I'll let it through," but when A pings B, then B says "Auugh! An unsolicited transmission! No doubt it's some blackguard worm, I'd better block it!"
Ping's the most basic troubleshooting tool in many a networker's arsenal, and it's a pain to try to do network troubleshooting in a network that's blocked all pings, as I discussed back in the DEP chapter. But pings are useful to more than folks trying to troubleshoot; several network protocols need ping to operate correctly. For example, part of group policy processing on a client needs an answer to the question, "Am I dialed up or directly connected via a high-speed network to my domain controller?" If the client's dialed up, then the client skips software installation (installing Word over a 56 Kbps connection wouldn't be fun), folder redirection (ditto), and login scripts. But how to know whether a system's dialed up or LAN-connected? Well, believe it or not, your system pings the domain controller, times how long it takes for the response, and guesses the connection speed from there. Of course, a DC with a ping-ignoring firewall in place never responds, and so every system in the network thinks it's dialed up, and that's not good, so let's see how to allow ICMP messages through WF.
Allowing Ping from the GUI
To open the door for pings from the GUI, bring up the Windows Firewall applet in Control Panel as you've done before: Start Control Panel Windows Firewall, and then click the Advanced tab; it'll look like Figure 8.11.
Click the Settings button in the ICMP section, and you'll see a dialog box like the one in Figure 8.12.
You see several different settings to allow different things in ICMP with check boxes next to them. You may have to check them all in some cases, but in my experience the only thing I tend to need is ICMP's incoming echo request. I've checked that box in the screen shot. To allow ping responses, check Allow Incoming Echo Request and click OK, then click OK to clear the WF property page. You'll then be able to ping the web server from the XP box, if you're following along in the examples.
Figure 8.11 Windows Firewall advanced property page
Figure 8.12 ICMP Settings dialog box
Once you've opened up ICMP responses, a netsh firewall show state won't reflect any changes. But add verbose=enable, and you'll get a lot more information, including this:
ICMP settings for all network interfaces:
|Disable||2||Allow outbound packet too big|
|Disable||3||Allow outbound destination unreachable|
|Disable||4||Allow outbound source quench|
|Enable||8||Allow inbound echo request|
|Disable||9||Allow inbound router request|
|Disable||11||Allow outbound time exceeded|
|Disable||12||Allow outbound parameter problem|
|Disable||13||Allow inbound timestamp request|
|Disable||17||Allow inbound mask request|
Notice the line with Enable 8 Allow inbound echo request; that's the one that shows you that this system will respond to pings.
Allowing Ping from the Command Line
Next, let's see how to allow ICMP echoes from the command line. (If you're following the examples, then go back to the Advanced tab and uncheck the box in ICMP Exceptions that allowed ICMP echoes.) To enable ICMP echoes from the command line, you'd type
netsh firewall set icmpsetting 8 enable
The 8 means "ICMP echo"; to see all of the other numeric values and what they correspond to in ICMP-ese, type netsh firewall set icmpsetting /?. (Again, I've never found a use for them.) Alternatively, you can open up the whole set of ICMP responses with
netsh firewall set icmpsetting all enable
After executing either command, the web server will again respond to pings. To disable either ICMP echo or all ICMP responses, just replace enable with disable on the command line. To stop ICMP echo so as to be able to reopen it again with a group policy setting, then, you'd type
netsh firewall set icmpsetting 8 disable
Allowing Ping from Group Policy settings
To allow ICMP echoes from group policy, return to the Group Policy Editor and the Standard Profile folder under Windows Firewall. Open up the setting Windows Firewall: Allow ICMP Exceptions and you'll see a dialog box like Figure 8.13.
Yours will probably have the Not Configured radio button clicked; I've clicked the Enabled radio button so you can more easily see the options. (Oddly enough, there's a scroll bar in this dialog box, but scrolling up or down doesn't show any more options, so you're not missing anything!)
Figure 8.13: All of the possible ICMP settings
The setting you're looking for here is Allow Inbound Echo Request. After clicking Enabled in your dialog box, check the box next to Allow Inbound Echo Request and then click OK. Again, the pings will flow freely. As before, netsh firewall show state won't show any difference without the verbose=enable parameter except to reveal in the Group policy version = Windows Firewall that group policy settings are somewhere afoot. As before, any attempts to override the group policy setting via command line or GUI will be ignored.
Mark Minasi is a best-selling author, commentator and all-around alpha geek. Mark is best known for his books in the Mastering Windows series. What separates him from others is that he knows how to explain technical things to normal humans, and make them laugh while doing it. Mark's firm, MR&D, is based in Pungo, a town in Virginia's Tidewater area that is distinguished by having one -- and only one -- traffic light.
Dig deeper on Endpoint security management tools