Problem solve Get help with specific problems with your technologies, process and projects.

Using Netsh with Windows Firewall

This tip examines how to configure and troubleshoot Windows Firewall using the Netsh command-line utility. The procedures covered apply to both the Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 operating system platforms.

This article originally appeared on

I've always had a liking for homes built of brick. Besides having a kind of "Lord of the Manor" appeal, they also...

look solidly built compared to many of today's wood-framed plastic-siding homes. Brick also gives an added sense of security since, who's going to smash through a brick wall to break into your house?

But then I wonder, wouldn't your home be even more secure if all the rooms had brick walls and not just the exterior wall of your house? After all, drywall is so fragile you can punch through it if you get really angry (and don't mind a bit of pain) so it seems like a good idea to make the internal walls brick also. That way if someone breaks into your house they still have to break into each individual room to find the safe where you keep your jewels.

Many corporate networks are just like this today—instead of relying only on a firewall at the perimeter (outside wall) of the network, there are firewalls installed on individual clients and servers (rooms) also to act as another layer of defense against attack. And on networks that run Windows XP on the clients and Windows Server 2003 on the servers, there's a ready candidate for which host-based firewall to use: Windows Firewall. After all, it's free!

Unfortunately having firewalls on clients and servers means extra management work as well, but Group Policy can handle that as far as Windows Firewall is concerned (another great reason for deploying Windows Firewall on hosts instead of third-party firewalls from other vendors). Still, there are times when you want to check or modify the configuration of Windows Firewall on some hosts because of problems of some sort, and the command-line tool Netsh.exe is just the thing to do this with.

Get It Working

Let's say Bob sets up a Windows Server 2003 SP1 machine as a web and file server for internal use in his company. Knowing that the Windows Firewall/Internet Connection Sharing service is disabled by default, he opens the Services console under Administrative Tools and changes the Startup Type for this service to Automatic and then starts the service. So far, so good, but if he had tried opening the Windows Firewall utility from Control Panel he would have been presented with a message asking him whether he wanted to start this service and pointing out that he should reboot his server afterwards to make sure Windows Firewall recognizes that the server is listening for inbound traffic from file and web clients.

Anyway, Bob now wants to enable and configure Windows Firewall on the server but is suddenly called away on an emergency. He sends a quick email to his assistant Mary using his BlackBerry saying "Enable firewall on server so clients can access it—get it working" and walks out the door. Unfortunately his assistant is working from home today but Bob remembered to enable Remote Desktop on the new server, so Mary starts Remote Desktop Connection on her Windows XP SP2 computer and the console of the remote server is displayed.

Now what? Mary could open Control Panel on the remote machine and enable Windows Firewall, but what exceptions does she need to configure on it? Bob was obviously in a hurry when he said "so clients can access it" but what clients? And it's obviously important because he wants it done today.

Rather than hunt around the Services console looking for additional services that Bob might have enabled on the machine, Mary decides to open a command prompt on the remote machine and pursue a different tack. She starts by typing the following command:

netstat –ano > netstat.txt
notepad netstat.txt

She then examines the contents of the netstat.txt file that opens in Notepad:

Active Connections
TCP Local Address Foreign Address State PID
------------ ---------------------------- ---------------------------- ---------------------- ------------

Right away it looks to her from this file that the server has the HTTP service installed on it since the machine is listening on TCP port 80. Better check though and make sure this service is actually the one using this port. How does she do this? First she notes the process ID (PID) number associated with these ports which is 1664. Then She types the following commands at the command prompt:

tasklist /svc > svclist.txt
notepad svclist.txt

She then examines the contents of the svclist.txt file, which look like this:

Image Name PID Services
--------------------- ------ -----------------------------
System Idle Process 0 N/A
System 4 N/A
smss.exe 260 N/A
csrss.exe 348 N/A
winlogon.exe 380 N/A
services.exe 424 Eventlog, PlugPlay
lsass.exe 436 HTTPFilter, Netlogon, PolicyAgent, ProtectedStorage, SamSs
svchost.exe 644 DcomLaunch
svchost.exe 696 RpcSs
svchost.exe 748 Dhcp, Dnscache
svchost.exe 796 LmHosts, W32Time
svchost.exe 812 AeLookupSvc, Browser, CryptSvc, dmserver, EventSystem, helpsvc, lanmanserver, lanmanworkstation, Netman, Nla, Schedule, seclogon, SENS, SharedAccess, ShellHWDetection, TrkWks, winmgmt, wuauserv, WZCSVC
spoolsv.exe 976 Spooler
msdtc.exe 1000 MSDTC
vmsrvc.exe 1120 1-vmsrvc
svchost.exe 1144 ERSvc
inetinfo.exe 1220 IISADMIN
svchost.exe 1288 RemoteRegistry
svchost.exe 1312 SrmSvc
vpcmap.exe 1420 VPCMap
svchost.exe 1664 W3SVC
svchost.exe 1780 TermService
alg.exe 1856 ALG
explorer.exe 972 N/A
vmusrvc.exe 1412 N/A
wuauclt.exe 2120 N/A
csrss.exe 2176 N/A
winlogon.exe 2204 N/A
rdpclip.exe 2452 N/A
explorer.exe 2556 N/A
wmiprvse.exe 2564 N/A
vmusrvc.exe 2648 N/A
cmd.exe 2724 N/A
tasklist.exe 2964 N/A
wmiprvse.exe 2988 N/A

She examines this file looking for the PID noted previously and finds this line:

svchost.exe 1664 W3SVC

This line confirms to her that Bob installed IIS on the server and configured it to run as a web server.

Now Mary has to enable Windows Firewall on the machine and create an exception for HTTP clients to access it. Since she's already at the command-line on the remote machine, she decides to do this using the Netsh command. First, she views the configuration of Windows Firewall on the server:

C:\>netsh firewall show opmode

Domain profile configuration (current):

------------------------- -------------------------
Operational mode = Disable
Exception mode = Enable

Standard profile configuration:

------------------------- -------------------------
Operational mode = Disable
Exception mode = Enable

Local Area Connection firewall configuration:

------------------------- -------------------------
Operational mode = Enable

From this command output she confirms that Windows Firewall is currently disabled and needs to be enabled. To do this, Mary types the following command:

C:\>netsh firewall set opmode enable

Now she adds a port exception for the HTTP service:

C:\>netsh firewall add portopening TCP 80 HTTP enable subnet

To test this, she temporarily minimizes her Remote Desktop Connection window and opens Internet Explorer and types in the address bar, and here's what she gets in response (Figure 1):

Figure 1: Accessing the server using HTTP

That sounds like Bob! Always playing the "heavy" as far as his role as administrator is concerned.

Now let's see what else is running on the server. Mary goes back to the netstat.txt file shown previously and finds the following lines of interest:


This is a sure giveaway that the server is configured as a file server with shared folders on it for these two ports (and two others listed below) are used by Server Message Block (SMB) protocol (Microsoft's file sharing protocol) as follows:

  • UDP port 137 is the listening port for the NETBIOS Name Service
  • UDP port 138 is the listening port for the NETBIOS Datagram Service
  • TCP port 139 is the listening port for the NETBIOS Session Service
  • TCP port 445 is the listening port for SMB over TCP/IP
  • In other words, the first three ports are for SMB over NBT (NETBIOS over TCP/IP) and the last one (new in Windows 2000 and later) is for SMB directly over TCP/IP.

    So to access the remote server as a file server, exceptions have to be created for these four ports in Windows Firewall. To do this, Mary types the following commands in the command prompt window open on the remote machine's desktop:

    netsh firewall add portopening UDP 137 blah enable subnet
    netsh firewall add portopening UDP 138 blah enable subnet
    netsh firewall add portopening TCP 139 blah enable subnet
    netsh firewall add portopening TCP 445 blah enable subnet

    What's cool about this approach is that if she opens Windows Firewall from Control Panel on the remote machine's desktop, it displays the File and Printer Sharing exception as enabled (Figure 2):

    Figure 2: File and Printer Sharing is enabled on the server

    Mary should then be able to display the shared folders on the remote server simply by clicking Start, then Run and typing \\ and clicking OK.


    Mary could have made her life easier by configuring Windows Firewall from the GUI instead of using Netsh since she was logged on in a remote desktop session anyways with the server, but then she wouldn't have had the opportunity of learning how to use Netsh, a really cool tool in the administrator's toolbox!

    One final point: before Mary logged off her RDC session she should have typed one more command on the server:

    netsh firewall add portopening TCP 3389 blah enable any

    Otherwise she won't be able to connect using RDC to the remote machine because once enabled, Windows Firewall blocks Remote Desktop sessions by default!

    About Mitch Tulloch:
    Mitch Tulloch is a writer, trainer and consultant specializing in Windows server operating systems, IIS administration, network troubleshooting, and security. He is the author of 15 books including the Microsoft Encyclopedia of Networking (Microsoft Press), the Microsoft Encyclopedia of Security (Microsoft Press), Windows Server Hacks (O'Reilly), Windows Server 2003 in a Nutshell (O'Reilly), Windows 2000 Administration in a Nutshell (O'Reilly), and IIS 6 Administration (Osborne/McGraw-Hill). Mitch is based in Winnipeg, Canada, and you can find more information about his books at his website contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles & tips by a team of leading authors, it remains a favorite within the networking community.
    This was last published in January 2006

    Dig Deeper on Network Security Best Practices and Products