Skip navigation
Controlling Windows Firewall with PowerShell

Controlling Windows Firewall with PowerShell

Stop turning off Windows Firewall and learn how to tame it!

Continuing on the theme of using Windows PowerShell and related tools to automate server setup—and in particular, to automate domain controller (DC) setup—let’s tackle what many consider to be one of the ugliest parts of setup: the firewall. (In this article, I’ll be configuring a Windows Server 2012/2012 R2 system.)

I know what you’re thinking: “Firewall? Are you crazy? We just turn it off. The servers are sitting behind our perimeter firewalls, anyway. Windows Firewall is just an unnecessary pain.” In response, I’d remind you that perimeter firewalls haven’t been sufficient protection for at least a decade. Also, a growing number of Microsoft tools require you to leave the firewall up. Ultimately, though, I think most people disable the firewall because controlling it seems too complicated, and that’s understandable. Shouldn’t enabling Ping be pretty easy? Well, it is—if you learn a few PowerShell cmdlets. So let’s dig in.

Six Options for Firewall Rules: Profiles and Direction

Consider the structure of firewall rules. Basically, each firewall rule exists to open or close a port or an application. For example, suppose you’re interested in allowing systems to use Remote Desktop Protocol (RDP) to connect to and control your server. At first glance, that should be easy: You need only tell Windows to open port 3389, on both the TCP and UDP protocols. With Windows Firewall, though, there isn’t just one rule for that task; there are six.

The six rules come from some Windows Firewall basics. First, the firewall has three personalities, which Windows Firewall calls profiles. The first profile, Domain, concerns traffic across a NIC that’s inside a domain. The second, Public, applies to NICs directly connected to the public Internet. Finally, the Private profile works on NICs connected to a network that’s shielded from the public Internet by a NAT router or a firewall but that isn’t running Active Directory (AD) traffic. (I’ll explain how Windows Firewall knows which profile to assign to a given NIC a bit later.) In addition to the “which profile?” question about any given firewall rule, there’s also direction: Does this rule apply to incoming or outgoing traffic? Three profiles times two directions, therefore, yield six possible rules, and so RDP requires not one rule but six.

It’s Not My Default: Incoming/Outgoing Rules

In theory, Windows Firewall could need a staggering number of rules: 65,536 incoming rules and 65,536 outgoing rules for TCP alone (and, of course, you’ve got to multiply that by six). In reality, however, you generally need to build explicit rules for no more than several dozen ports and/or apps. Windows Firewall knows what to do on the unmentioned ports because PowerShell lets you define default rules with the set-NetFirewallProfile command, which looks like

set-netfirewallprofile profilename| -all -DefaultInboundAction Allow|Block -DefaultOutboundAction Allow|Block

The profilename parameter can take the values Public, Private, and Domain. If you’ve been following this column for a while or have some basic skills with PowerShell, you’ll probably quickly guess that you can find the current settings for your system with the following command (and remember to type it as just one line):

get-netfirewallprofile | select name,DefaultInboundAction,DefaultOutBoundAction | ft -a

That command displays your three profiles and their default inbound and outbound actions. Run it on most systems and you’ll see that Windows Firewall’s default approach is to block all inbound ports and leave all outbound ports open. You can skip the -profilename name parameter and just substitute -all to control all three profiles. Thus, to drop the firewall altogether, you could type

set-netfirewallprofile -all -DefaultInboundAction Allow -DefaultOutboundAction Allow

And if you do that, Windows will start complaining that it’s a bad idea. Restore things to the default state with

set-netfirewallprofile -all -DefaultInboundAction Block -DefaultOutboundAction Allow

Controlling Which Profile Controls What NIC

Windows Firewall assigns any active network connection, whether a NIC or a “fake” NIC (e.g., a VPN connection), to one of the three firewall profiles. To see which profile Windows Firewall has assigned to each connection, you can use the command

get-NetConnectionProfile

That results in information such as the following (this sample system currently has only wireless networking enabled):

Name : Signature
InterfaceAlias : Wi-Fi 2
InterfaceIndex : 8
NetworkCategory : Public
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

In this public Wi-Fi scenario, Windows has correctly given the NIC the Public profile. But what if you want to change that, in some situation where Windows Firewall guessed wrong? Then you’d use the Set-NetConnectionProfile cmdlet, which looks like

set-NetConnectionProfile -interfacealias name -NetworkCategory profilename

And in that case, you could set the profile to Private with the command

set-NetConnectionProfile -interfacealias "Wi-Fi 2" -NetworkCategory Private

That’s almost everything you need to know about bending the Windows Firewall to your will, except for one thing: How do you open a specific port? I’ll tackle that question next month. Until then, turn those firewalls back on!

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish