Tutorials

Managing the Windows 2012 R2 Firewall with PowerShell

Table of Contents

Introduction

Microsoft provides a variety of ways to manage the built-in Windows 2012 R2 firewall. The focus of this tutorial will be using PowerShell 4.0 to manage the local machine's policies. However, before you begin, you will need access to a Windows server. If you do not have a Windows server then you can easily deploy one using the Data Center Designer.

Basics

Any Windows server deployed on the ProfitBricks platform has its local firewall policy enabled by default.

There are three global profile defaults for the firewall. These are:

  • Domain
  • Private
  • Public

Domain

This profile would apply to machines which authenticate and participate in an Active Directory domain.

Private

This profile would apply to any private traffic.

Public

This profile would apply to any public traffic.

You can choose to protect all or none of your network interfaces with any of the above profiles. By default, all interfaces are protected by all profiles and all profiles are enabled by default. The downside to this default setup is that if you add any rules you need to ensure those rules are carried across into all other profiles. This is the recommended practice from Microsoft; however, this introduces some overhead on management. A simpler way to solve this issue is to define the role of the interface, e.g. internal IP traffic, then protect that interface using only the private or domain profile. This ensures that you can create broader rules that apply to internal traffic, while not being put in a position where you need to carry that rule over to your public interface.

Firewall PowerShell Commands

You can retrieve a list of firewall commands using the following query:

Get-Command *-*firewall

Checking Protected Network Connections

You can view the network interfaces that are not being protected by a profile by doing this:

Get-NetFirewallProfile -Name Public | fl DisabledInterfaceAliases

Since default is that all interfaces are protected and therefore this should return as:

DisabledInterfaceAliases : {NotConfigured}

You can remove a interface from being protected by the profile:

Set-NetFirewallProfile -Name Public -DisabledInterfaceAliases "nic_name"

Listing Inbound Rules

You can retrieve a list of inbound rules that apply to all profiles or just the public profile by doing:

Get-NetFirewallRule | where {$_.Direction -eq "Inbound" -and (($_.Profile -contains "Any") -or ($_.Profile -contains "Public"))}

A majority of the built-in rules apply to all profiles, however, sometimes you want to ensure a narrow range of ports are opened for public connections, while keeping a broader range of ports open for private connections.

Adding an Inbound Rule

If you are working with an application that needs a port exposed you will need to add an inbound exception for this port. Using the Public profile as an example you could do:

New-NetFirewallRule -Name "Custom App Rule (in)" -Description "Our Custom App Rule" -DisplayName "Custom App Rule" -Enabled:True -Profile Public -Direction Inbound -Action Allow -Protocol TCP -LocalPort 4000

This will create an inbound rule and assign it to the Public profile. It will open up and allow traffic to transit port 4000/TCP.

If you omit Direction, Enabled, and Action they will default to Inbound, True, and Allow, respectively. Leaving protocol and any of the port parameters empty will result in those values being set to Any.

Removing an Inbound Rule

You can either remove or disable an inbound rule.

To disable a rule you would:

Get-NetFirewallRule -Name "Custom App Rule (in)" | Disable-NetFirewallRule

Re-enabling would simply be done by replacing Disable-NetFirewallRule with Enable-NetFirewallRule.

To completely remove the rule you would:

Get-NetFirewallRule -Name "Custom App Rule (in)" | Remove-NetFirewallRule

A note of caution here. There is always a potential that you can accidentally remove or disable a rule that controls access to your instance. If this occurs you can regain connectivity to the instance by going through the DCD and logging in via the console.

Updating an Existing Rule

You can update any of the firewall rules by first getting the rule then passing it to a Set-* command:

Get-NetFirewallRule -Name "Custom App Rule (in)" | Set-NetFirewallRule -Action Block

This would switch the rule you just created from being allowed to being blocked.

Logging Locations

When troubleshooting firewall rules your best place outside of the Event Log is to read through the text log generated.

The firewall log path is:

%systemroot%\system32\LogFiles\Firewall

The logfile name is 'pfirewall.log'.

Out of the box the log is configured to limit growth to 4,096KB. This can be adjusted either per machine or via Group Policy if you're on a domain.

Conclusion

We plan on covering additional, more advanced firewall topics in future tutorials. This article serves as a starting point for your understanding of the basics.

 
Log In, Add a Comment