title: Configure the Windows Defender Firewall Log
description: Learn how to configure Windows Defender Firewall with Advanced Security to log dropped packets or successful connections by using Group Policy Management MMC.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure the Windows Defender Firewall with Advanced Security Log
To configure Windows Defender Firewall with Advanced Security to log dropped packets or successful connections, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management MMC snap-in.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
## To configure the Windows Defender Firewall with Advanced Security log
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane, in the **Overview** section, click **Windows Defender Firewall Properties**.
3. For each network location type (Domain, Private, Public), perform the following steps.
1. Click the tab that corresponds to the network location type.
2.Under **Logging**, click **Customize**.
3. The default path for the log is **%windir%\\system32\\logfiles\\firewall\\pfirewall.log**. If you want to change this path, clear the **Not configured** check box and type the path to the new location, or click **Browse** to select a file location.
1. Click the tab that corresponds to the network location type
2. Under **Logging**, click **Customize**
3.The default path for the log is **%windir%\system32\logfiles\firewall\pfirewall.log**. If you want to change this path, clear the **Not configured** check box and type the path to the new location, or click **Browse** to select a file location
> [!IMPORTANT]
> The location you specify must have permissions assigned that permit the Windows Defender Firewall service to write to the log file.
5. The default maximum file size for the log is 4,096 kilobytes (KB). If you want to change this size, clear the **Not configured** check box, and type in the new size in KB, or use the up and down arrows to select a size. The file won't grow beyond this size; when the limit is reached, old log entries are deleted to make room for the newly created ones.
6. No logging occurs until you set one of following two options:
- To create a log entry when Windows Defender Firewall drops an incoming network packet, change **Log dropped packets** to **Yes**.
- To create a log entry when Windows Defender Firewall allows an inbound connection, change **Log successful connections** to **Yes**.
7. Click **OK** twice.
- To create a log entry when Windows Defender Firewall drops an incoming network packet, change **Log dropped packets** to **Yes**
- To create a log entry when Windows Defender Firewall allows an inbound connection, change **Log successful connections** to **Yes**
7. Click **OK** twice
### Troubleshoot if the log file is not created or modified
@ -91,4 +77,4 @@ Restart the device to restart the Windows Defender Firewall Service.
### Troubleshoot Slow Log Ingestion
If logs are slow to appear in Sentinel, you can turn down the log file size. Just beware that this downsizing will result in more resource usage due to the increased resource usage for log rotation.
If logs are slow to appear in Sentinel, you can turn down the log file size. Just beware that this downsizing will result in more resource usage due to the increased resource usage for log rotation.
description: Learn how to allow inbound ICMP traffic by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
description: Learn to allow traffic on specific ports by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Inbound Port Rule
To allow inbound network traffic on only a specified TCP or UDP port number, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows any program that listens on a specified TCP or UDP port to receive network traffic sent to that port.
To allow inbound network traffic on only a specified TCP or UDP port number, use the Windows Defender Firewall
with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows any program that listens on a specified TCP or UDP port to receive network traffic sent to that port.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
This topic describes how to create a standard port rule for a specified protocol or TCP or UDP port number. For other inbound port rule types, see:
- [Create an Inbound ICMP Rule](create-an-inbound-icmp-rule.md)
- [Create Inbound Rules to Support RPC](create-inbound-rules-to-support-rpc.md)
**To create an inbound port rule**
To create an inbound port rule
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
description: Learn to block outbound traffic on a port by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Outbound Port Rule
# Create an Outbound Port Rule with group policy
By default, Windows Firewall allows all outbound network traffic, unless it matches a rule that prohibits the traffic. To block outbound network traffic on a specified TCP or UDP port number, use the *Windows Defender Firewall with Advanced Security* node in the Group Policy Management console to create firewall rules. This type of rule blocks any outbound network traffic that matches the specified TCP or UDP port numbers.
By default, Windows Defender Firewall allows all outbound network traffic unless it matches a rule that prohibits the traffic. To block outbound network traffic on a specified TCP or UDP port number, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create firewall rules. This type of rule blocks any outbound network traffic that matches the specified TCP or UDP port numbers.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
> [!NOTE]
> To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To create an outbound port rule
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md)
1. In the navigation pane, select **Outbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Outbound Rule wizard, select **Custom**, and then select **Next**
2. In the navigation pane, click **Outbound Rules**.
> [!NOTE]
> Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
3. Click **Action**, and then click **New rule**.
1.On the **Program** page, select **All programs**, and then select **Next**
1. On the **Protocol and Ports** page, select the protocol type that you want to block. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this rule is an outbound rule, you typically configure only the remote port number
4. On the **Rule Type** page of the New Outbound Rule wizard, click **Custom**, and then click**Next**.
If you select another protocol, then only packets whose protocol field in the IP header matches this rule are blocked by Windows Defender Firewall. Network traffic for protocols is allowed as long as other rules that match don't block it. To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box. When you've configured the protocols and ports, select**Next**,
>**Note:**Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
5. On the **Program** page, click **All programs**, and then click**Next**.
6. On the **Protocol and Ports** page, select the protocol type that you want to block. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this rule is an outbound rule, you typically configure only the remote port number.
If you select another protocol, then only packets whose protocol field in the IP header matches this rule are blocked by Windows Defender Firewall. Network traffic for protocols is allowed as long as other rules that match don't block it.
To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box.
When you've configured the protocols and ports, click **Next**.
7. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
8. On the **Action** page, select **Block the connection**, and then click **Next**.
9. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
10. On the **Name** page, type a name and description for your rule, and then click **Finish**.
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addressesentered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Block the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select**Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
description: Use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create firewall rules.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
ms.date: 11/13/2023
---
# Create an Outbound Program or Service Rule
By default, Windows Defender Firewall allows all outbound network traffic unless it matches a rule that prohibits the traffic. To block outbound network traffic for a specified program or service, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create firewall rules. This type of rule prevents the program from sending any outbound network traffic on any port.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To create an outbound firewall rule for a program or service
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
1. In the navigation pane, select **Outbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Outbound Rule Wizard, select **Custom**, and then select **Next**
2. In the navigation pane, click **Outbound Rules**.
> [!NOTE]
> Although you can create many rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
3. Click **Action**, and then click **New rule**.
1.On the **Program** page, select **This program path**
1. Type the path to the program in the text box. Use environment variables as appropriate to ensure that programs installed in different locations on different computers work correctly
1. Do one of the following:
4. On the **Rule Type** page of the New Outbound Rule Wizard, click **Custom**, and then click**Next**.
- If the executable file contains a single program, select**Next**
- If the executable file is a container for multiple services that must all be blocked from sending outbound network traffic, select **Customize**, select **Apply to services only**, select **OK**, and then select **Next**
- If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, select **Customize**, select **Apply to this service**, and then select the service from the list. If the service does not appear in the list, then select **Apply to service with this service short name**, and type the short name for the service in the text box. Select **OK**, and then select **Next**
>**Note:**Although you can create many rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
5. On the **Program** page, click **This program path**.
6. Type the path to the program in the text box. Use environment variables as appropriate to ensure that programs installed in different locations on different computers work correctly.
7. Do one of the following:
- If the executable file contains a single program, click **Next**.
- If the executable file is a container for multiple services that must all be blocked from sending outbound network traffic, click **Customize**, select **Apply to services only**, click **OK**, and then click **Next**.
- If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, click **Customize**, select **Apply to this service**, and then select the service from the list. If the service does not appear in the list, then click **Apply to service with this service short name**, and type the short name for the service in the text box. Click **OK**, and then click **Next**.
8. If you want the program to be allowed to send on some ports, but blocked from sending on others, then you can restrict the firewall rule to block only the specified ports or protocols. On the **Protocols and Ports** page, you can specify the port numbers or protocol numbers for the blocked traffic. If the program tries to send to or from a port number different from the one specified here, or by using a protocol number different from the one specified here, then the default outbound firewall behavior allows the traffic. For more information about the protocol and port options, see [Create an Outbound Port Rule](create-an-outbound-port-rule.md). When you have configured the protocol and port options, click **Next**.
9. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
10. On the **Action** page, select **Block the connection**, and then click **Next**.
11. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
12. On the **Name** page, type a name and description for your rule, and then click **Finish**.
1. If you want the program to be allowed to send on some ports, but blocked from sending on others, then you can restrict the firewall rule to block only the specified ports or protocols. On the **Protocols and Ports** page, you can specify the port numbers or protocol numbers for the blocked traffic. If the program tries to send to or from a port number different from the one specified here, or by using a protocol number different from the one specified here, then the default outbound firewall behavior allows the traffic. For more information about the protocol and port options, see [Create an Outbound Port Rule](create-an-outbound-port-rule.md). When you have configured the protocol and port options, select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Block the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1.On the **Name** page, type a name and description for your rule, and then select **Finish**
description: Learn how to allow RPC network traffic by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
title: Designing a Windows Defender Firewall Strategy
description: Answer the question in this article to design an effective Windows Defender Firewall with Advanced Security Strategy.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Designing a Windows Defender Firewall with Advanced Security Strategy
To select the most effective design for helping to protect the network, you must spend time collecting key information about your current computer environment. You must have a good understanding of what tasks the devices on the network perform, and how they use the network to accomplish those tasks. You must understand the network traffic generated by the programs running on the devices.
- [Gathering the Information You Need](gathering-the-information-you-need.md)
- [Determining the Trusted State of Your Devices](determining-the-trusted-state-of-your-devices.md)
The information that you gather will help you answer the following questions. The answers will help you understand your security requirements and select the design that best matches those requirements. The information will also help you when it comes time to deploy your design, by helping you to build a deployment strategy that is cost effective and resource efficient. It will help you project and justify the expected costs associated with implementing the design.
- What traffic must always be allowed? What are characteristics of the network traffic generated and consumed by the business programs?
- What traffic must always be blocked? Does your organization have policies that prohibit the use of specific programs? If so, what are the characteristics of the network traffic generated and consumed by the prohibited programs?
- What traffic on the network can't be protected by IPsec because the devices or devices sending or receiving the traffic don't support IPsec?
- For each type of network traffic, does the default configuration of the firewall (block all unsolicited inbound network traffic, allow all outbound traffic) allow or block the traffic as required?
- Do you have an Active Directory domain (or forest of trusted domains) to which all your devices are joined? If you don't, then you can't use Group Policy for easy mass deployment of your firewall and connection security rules. You also can't easily take advantage of KerberosV5 authentication that all domain clients can use.
- Which devices must be able to accept unsolicited inbound connections from devices that aren't part of the domain?
- Which devices contain data that must be encrypted when exchanged with another computer?
- Which devices contain sensitive data to which access must be restricted to authorized users and devices?
- Does your organization have specific network troubleshooting devices or devices (such as protocol analyzers) that must be granted unlimited access to the devices on the network, essentially bypassing the firewall?
This guide describes how to plan your groups and GPOs for an environment with a mix of operating systems. Details can be found in the section [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) later in this guide.
**Next:** [Gathering the Information You Need](gathering-the-information-you-need.md)
title: Windows Defender Firewall with Advanced Security
description: Learn overview information about the Windows Defender Firewall with Advanced Security (WFAS) and Internet Protocol security (IPsec) features.
title: Isolating Microsoft Store Apps on Your Network
description: Learn how to customize your firewall configuration to isolate the network access of the new Microsoft Store apps that run on devices added to your network.
description: Quarantine behavior is explained in detail.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
@ -28,13 +27,13 @@ The quarantine feature creates filters that can be split into three categories:
These filters are added in the FWPM_SUBLAYER_MPSSVC_QUARANTINE sublayer and these layers are:
1.FWPM_LAYER_ALE_AUTH_CONNECT_V4
1. FWPM_LAYER_ALE_AUTH_CONNECT_V4
2.FWPM_LAYER_ALE_AUTH_CONNECT_V6
2. FWPM_LAYER_ALE_AUTH_CONNECT_V6
3.FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
3. FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
4.FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6
4. FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6
>[!NOTE]
> Any firewall rules added by the customers will not affect the filters in the quarantine sublayer as filters from Firewall rules are added in the FWPM_SUBLAYER_MPSSVC_WF sublayer. In other words, customers cannot add their own exception filters to prevent packets from being evaluated by quarantine filters.
@ -57,17 +56,17 @@ The interface un-quarantine filters allow all non-loopback packets if the interf
The following events describe the general flow of quarantine:
1.There's some change on the current network interface.
1. There's some change on the current network interface.
2.The interface un-quarantine filters will no longer permit new inbound connections. The interface is now in quarantine state.
2. The interface un-quarantine filters will no longer permit new inbound connections. The interface is now in quarantine state.
3.All non-loopback inbound connections are either permitted by quarantine default exception filters or dropped by the quarantine default inbound block filter.
3. All non-loopback inbound connections are either permitted by quarantine default exception filters or dropped by the quarantine default inbound block filter.
4.The WFP filters applicable to the old interface state are removed.
4. The WFP filters applicable to the old interface state are removed.
5. The WFP filters applicable to the new interface state are added, which include the un-quarantine filters for this interface. These filters are updated to match the interface's current state.
6.The interface has now exited quarantine state as the interface un-quarantine filters permit any new non-loopback packets.
6. The interface has now exited quarantine state as the interface un-quarantine filters permit any new non-loopback packets.
## Quarantine diagnostics
@ -88,7 +87,7 @@ Inside the wfpdiag.xml, search for `netEvents` that have `FWPM_NET_EVENT_TYPE_CL
The characters in the application ID name will be separated by periods:
The `netEvent` will have more information about the packet that was dropped including information about its capabilities, the filter that dropped the packet, and much more.
@ -186,7 +185,7 @@ Sample drop audit with `filterOrigin` as `Quarantine Default`.
Once the drop’s filter origin has been identified as the quarantine default inbound block filter, the interface should be further investigated. To find the relevant interface, use the `InterfaceIndex` value from the `netEvent` or event audit in the following PowerShell command to generate more information about the interface:
Once the drop's filter origin has been identified as the quarantine default inbound block filter, the interface should be further investigated. To find the relevant interface, use the `InterfaceIndex` value from the `netEvent` or event audit in the following PowerShell command to generate more information about the interface:
title: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012
description: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
@ -158,7 +157,7 @@ Follow these procedures to verify and troubleshoot your IKEv2 IPsec connections:
5. Open the cab file, and then extract the wfpdiag.xml file.
6. Open the wfpdiag.xml file with your an XML viewer program or Notepad, and then examine the contents. There will be a lot of data in this file. One way to narrow down where to start looking is to search the last “errorFrequencyTable” at the end of the file. There might be many instances of this table, so make sure that you look at the last table in the file. For example, if you have a certificate problem, you might see the following entry in the last table at the end of the file:
6. Open the wfpdiag.xml file with your an XML viewer program or Notepad, and then examine the contents. There will be a lot of data in this file. One way to narrow down where to start looking is to search the last "errorFrequencyTable" at the end of the file. There might be many instances of this table, so make sure that you look at the last table in the file. For example, if you have a certificate problem, you might see the following entry in the last table at the end of the file:
title: Windows Defender Firewall with Advanced Security Administration with Windows PowerShell
description: Windows Defender Firewall with Advanced Security Administration with Windows PowerShell
ms.prod: windows-client
description: Windows Defender Firewall with Advanced Security Administration with
ms.topic: conceptual
ms.date: 09/08/2021
---
# Windows Defender Firewall with Advanced Security Administration with Windows PowerShell
# Windows Defender Firewall with Advanced Security Administration with
The Windows Defender Firewall with Advanced Security Administration with Windows PowerShell Guide provides essential scriptlets for automating Windows Defender Firewall management. It's designed for IT pros, system administrators, IT managers, and others who use and need to automate Windows Defender Firewall management in Windows.
You can use Windows PowerShell to manage your firewall and IPsec deployments. This object-oriented scripting environment will make it easier for you to manage policies and monitor network conditions than was possible in netsh. Windows PowerShell allows network settings to be self-discoverable through the syntax and parameters in each of the cmdlets. This guide demonstrates how common tasks were performed in netsh and how you can use Windows PowerShell to accomplish them.
In future versions of Windows, Microsoft might remove the netsh functionality for Windows Defender Firewall. Microsoft recommends that you transition to Windows PowerShell if you currently use netsh to configure and manage Windows Defender Firewall.
Windows PowerShell and netsh command references are at the following locations.
- [Netsh Commands for Windows Defender Firewall](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc771920(v=ws.10))
- [Netsh Commands for Windows Defender Firewall](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc771920(v=ws.10))
## Scope
This guide doesn't teach you the fundamentals of Windows Defender Firewall, which can be found in [Windows Defender Firewall](windows-firewall-with-advanced-security.md). It doesn't teach the fundamentals of Windows PowerShell, and it assumes that you're familiar with the Windows PowerShell language and the basic concepts of Windows PowerShell. For more info about Windows PowerShell concepts and usage, see the reference topics in the [Additional resources](#other-resources) section of this guide.
## Audience and user requirements
This guide is intended for IT pros, system administrators, and IT managers, and it assumes that you're familiar with Windows Defender Firewall, the Windows PowerShell language, and the basic concepts of Windows PowerShell.
## In this topic
| Section | Description |
| - | - |
| [Set profile global defaults](#bkmk-profileglobaldefaults) | Enable and control firewall behavior|
@ -37,650 +23,401 @@ This guide is intended for IT pros, system administrators, and IT managers, and
| [Deploy secure firewall rules with IPsec](#deploy-secure-firewall-rules-with-ipsec) | Domain and server isolation|
| [Other resources](#other-resources) | More information about Windows PowerShell|
## <a href="" id="bkmk-profileglobaldefaults"></a>Set profile global defaults
## Set profile global defaults
Global defaults set the device behavior in a per-profile basis. Windows Defender Firewall supports Domain, Private, and Public profiles.
### Enable Windows Defender Firewall with Advanced Security
Windows Defender Firewall drops traffic that doesn't correspond to allowed unsolicited traffic, or traffic that is sent in response to a request by the device. If you find that the rules you create aren't being enforced, you may need to enable Windows Defender Firewall. Here's how to enable Windows Defender Firewall on a local domain device:
### Control Windows Defender Firewall with Advanced Security behavior
The global default settings can be defined through the command-line interface. These modifications are also available through the Windows Defender Firewall with Advanced Security console.
The following scriptlets set the default inbound and outbound actions, specifies protected network connections, and allows notifications to be displayed to the user when a program is blocked from receiving inbound connections. It allows unicast response to multicast or broadcast network traffic, and it specifies logging settings for troubleshooting.
**Netsh**
``` syntax
```cmd
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound
netsh advfirewall set allprofiles settings inboundusernotification enable
netsh advfirewall set allprofiles settings unicastresponsetomulticast enable
netsh advfirewall set allprofiles logging filename %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
### Disable Windows Defender Firewall with Advanced Security
Microsoft recommends that you don't disable Windows Defender Firewall because you lose other benefits provided by the service, such as the ability to use Internet Protocol security (IPsec) connection security rules, network protection from attacks that employ network fingerprinting, [Windows Service Hardening](https://go.microsoft.com/fwlink/?linkid=104976), and [boot time filters](https://blogs.technet.microsoft.com/networking/2009/03/24/stopping-the-windows-authenticating-firewall-service-and-the-boot-time-policy/).
Disabling Windows Defender Firewall with Advanced Security can also cause problems, including:
- Start menu can stop working
- Modern applications can fail to install or update
- Activation of Windows via phone fails
- Application or OS incompatibilities that depend on Windows Defender Firewall
Microsoft recommends disabling Windows Defender Firewall only when installing a third-party firewall, and resetting Windows Defender Firewall back to defaults when the third-party software is disabled or removed.
If disabling Windows Defender Firewall is required, don't disable it by stopping the Windows Defender Firewall service (in the **Services** snap-in, the display name is Windows Defender Firewall and the service name is MpsSvc).
Stopping the Windows Defender Firewall service isn't supported by Microsoft.
Non-Microsoft firewall software can programmatically disable only the parts of Windows Defender Firewall that need to be disabled for compatibility.
You shouldn't disable the firewall yourself for this purpose.
The proper method to disable the Windows Defender Firewall is to disable the Windows Defender Firewall Profiles and leave the service running.
Use the following procedure to turn off the firewall, or disable the Group Policy setting **Computer Configuration|Administrative Templates|Network|Network Connections|Windows Defender Firewall|Domain Prolfile|Windows Defender Firewall:Protect all network connections**.
For more information, see [Windows Defender Firewall with Advanced Security deployment guide](windows-firewall-with-advanced-security-deployment-guide.md).
The following example disables Windows Defender Firewall for all profiles.
This section provides scriptlet examples for creating, modifying, and deleting firewall rules.
### Create firewall rules
Adding a firewall rule in Windows PowerShell looks a lot like it did in Netsh, but the parameters and values are specified differently.
Here's an example of how to allow the Telnet application to listen on the network. This firewall rule is scoped to the local subnet by using a keyword instead of an IP address. Just like in Netsh, the rule is created on the local device, and it becomes effective immediately.
The following scriptlet shows how to add a basic firewall rule that blocks outbound traffic from a specific application and local port to a Group Policy Object (GPO) in Active Directory. In Windows PowerShell, the policy store is specified as a parameter within the **New-NetFirewall** cmdlet. In Netsh, you must first specify the GPO that the commands in a Netsh session should modify. The commands you enter are run against the contents of the GPO, and the execution remains in effect until the Netsh session is ended or until another set store command is executed.
Here, **domain.contoso.com** is the name of your Active Directory Domain Services (ADDS), and **gpo\_name** is the name of the GPO that you want to modify. Quotation marks are required if there are any spaces in the GPO name.
**Netsh**
``` syntax
```cmd
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
To reduce the burden on busy domain controllers, Windows PowerShell allows you to load a GPO to your local session, make all your changes in that session, and then save it back at all once.
The following command performs the same actions as the previous example (by adding a Telnet rule to a GPO), but we do so by applying GPO caching in PowerShell. Changing the GPO by loading it onto your local session and using the *-GPOSession* parameter aren't supported in Netsh
This command doesn't batch your individual changes, it loads and saves the entire GPO at once. So if any other changes are made by other administrators, or in a different Windows PowerShell window, saving the GPO overwrites those changes.
### Modify an existing firewall rule
When a rule is created, Netsh and Windows PowerShell allow you to change rule properties and influence, but the rule maintains its unique identifier (in Windows PowerShell, this identifier is specified with the *-Name* parameter).
For example, you could have a rule **Allow Web 80** that enables TCP port 80 for inbound unsolicited traffic. You can change the rule to match a different remote IP address of a Web server whose traffic will be allowed by specifying the human-readable, localized name of the rule.
**Netsh**
``` syntax
```cmd
netsh advfirewall firewall set rule name="Allow Web 80" new remoteip=192.168.0.2
```
Windows PowerShell
```powershell
Set-NetFirewallRule –DisplayName “Allow Web 80” -RemoteAddress 192.168.0.2
Set-NetFirewallRule -DisplayName "Allow Web 80" -RemoteAddress 192.168.0.2
```
Netsh requires you to provide the name of the rule for it to be changed and we don't have an alternate way of getting the firewall rule. In Windows PowerShell, you can query for the rule using its known properties.
When you run `Get-NetFirewallRule`, you may notice that common conditions like addresses and ports don't appear. These conditions are represented in separate objects called Filters. As shown before, you can set all the conditions in New-NetFirewallRule and Set-NetFirewallRule. If you want to query for firewall rules based on these fields (ports, addresses, security, interfaces, services), you'll need to get the filter objects themselves.
You can change the remote endpoint of the **Allow Web 80** rule (as done previously) using filter objects. Using Windows PowerShell, you query by port using the port filter, then assuming other rules exist affecting the local port, you build with further queries until your desired rule is retrieved.
In the following example, we assume the query returns a single firewall rule, which is then piped to the `Set-NetFirewallRule` cmdlet utilizing Windows PowerShell’s ability to pipeline inputs.
Windows PowerShell
In the following example, we assume the query returns a single firewall rule, which is then piped to the `Set-NetFirewallRule` cmdlet utilizing Windows PowerShell's ability to pipeline inputs.
You can also query for rules using the wildcard character. The following example returns an array of firewall rules associated with a particular program. The elements of the array can be modified in subsequent `Set-NetFirewallRule` cmdlets.
Multiple rules in a group can be simultaneously modified when the associated group name is specified in a Set command. You can add firewall rules to specified management groups in order to manage multiple rules that share the same influences.
In the following example, we add both inbound and outbound Telnet firewall rules to the group **Telnet Management**. In Windows PowerShell, group membership is specified when the rules are first created so we re-create the previous example rules. Adding rules to a custom rule group isn't possible in Netsh.
If the group isn't specified at rule creation time, the rule can be added to the rule group using dot notation in Windows PowerShell. You can't specify the group using `Set-NetFirewallRule` since the command allows querying by rule group.
With the help of the `Set` command, if the rule group name is specified, the group membership isn't modified but rather all rules of the group receive the same modifications indicated by the given parameters.
The following scriptlet enables all rules in a predefined group containing remote management influencing firewall rules.
**Netsh**
``` syntax
```cmd
netsh advfirewall firewall set rule group="Windows Defender Firewall remote management" new enable=yes
Rule objects can be disabled so that they're no longer active. In Windows PowerShell, the **Disable-NetFirewallRule** cmdlet will leave the rule on the system, but put it in a disabled state so the rule no longer is applied and impacts traffic. A disabled firewall rule can be re-enabled by **Enable-NetFirewallRule**. This cmdlet is different from the **Remove-NetFirewallRule**, which permanently removes the rule definition from the device.
The following cmdlet deletes the specified existing firewall rule from the local policy store.
**Netsh**
``` syntax
netsh advfirewall firewall delete rule name=“Allow Web 80”
```cmd
netsh advfirewall firewall delete rule name="Allow Web 80"
```
Windows PowerShell
```powershell
Remove-NetFirewallRule –DisplayName “Allow Web 80”
Remove-NetFirewallRule -DisplayName "Allow Web 80"
```
Like with other cmdlets, you can also query for rules to be removed. Here, all blocking firewall rules are deleted from the device.
Windows PowerShell
```powershell
Remove-NetFirewallRule –Action Block
Remove-NetFirewallRule -Action Block
```
It may be safer to query the rules with the **Get** command and save it in a variable, observe the rules to be affected, then pipe them to the **Remove** command, just as we did for the **Set** commands. The following example shows how you can view all the blocking firewall rules, and then delete the first four rules.
Windows PowerShell
```powershell
$x = Get-NetFirewallRule –Action Block
$x = Get-NetFirewallRule -Action Block
$x
$x[0-3] | Remove-NetFirewallRule
```
## Manage remotely
Remote management using WinRM is enabled by default. The cmdlets that support the *CimSession* parameter use WinRM and can be managed remotely by default.
The following example returns all firewall rules of the persistent store on a device named **RemoteDevice**.
Windows PowerShell
```powershell
Get-NetFirewallRule -CimSession RemoteDevice
```
We can perform any modifications or view rules on remote devices by using the *-CimSession* parameter. Here we remove a specific firewall rule from a remote device.
We can perform any modifications or view rules on remote devices by using the *–CimSession* parameter. Here we remove a specific firewall rule from a remote device.
An Internet Protocol security (IPsec) policy consists of rules that determine IPsec behavior. IPsec supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Windows PowerShell can create powerful, complex IPsec policies like in Netsh and the Windows Defender Firewall with Advanced Security console. However, because Windows PowerShell is object-based rather than string token-based, configuration in Windows PowerShell offers greater control and flexibility.
In Netsh, the authentication and cryptographic sets were specified as a list of comma-separated tokens in a specific format. In Windows PowerShell, rather than using default settings, you first create your desired authentication or cryptographic proposal objects and bundle them into lists in your preferred order. Then, you create one or more IPsec rules that reference these sets. The benefit of this model is that programmatic access to the information in the rules is much easier. See the following sections for clarifying examples.
### Create IPsec rules
The following cmdlet creates basic IPsec transport mode rule in a Group Policy Object. An IPsec rule is simple to create; all that is required is the display name, and the remaining properties use default values. Inbound traffic is authenticated and integrity checked using the default quick mode and main mode settings. These default settings can be found in the console under Customize IPsec Defaults.
**Netsh**
``` syntax
```cmd
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
### Add custom authentication methods to an IPsec rule
If you want to create a custom set of quick-mode proposals that includes both AH and ESP in an IPsec rule object, you create the associated objects separately and link their associations. For more information about authentication methods, see [Choosing the IPsec Protocol](/previous-versions/windows/it-pro/windows-server-2003/cc757847(v=ws.10)) .
You can then use the newly created custom quick-mode policies when you create IPsec rules. The cryptography set object is linked to an IPsec rule object.
In this example, we build on the previously created IPsec rule by specifying a custom quick-mode crypto set. The final IPsec rule requires outbound traffic to be authenticated by the specified cryptography method.
**Netsh**
``` syntax
```cmd
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
A corporate network may need to secure communications with another agency. But, you discover the agency runs non-Windows operating systems and requires the use of the Internet Key Exchange Version2 (IKEv2) standard.
You can apply IKEv2 capabilities in Windows Server 2012 by specifying IKEv2 as the key module in an IPsec rule. This capability specification can only be done using computer certificate authentication and can't be used with phase-2 authentication.
For more info about IKEv2, including scenarios, see [Securing End-to-End IPsec Connections by Using IKEv2](securing-end-to-end-ipsec-connections-by-using-ikev2.md).
### Copy an IPsec rule from one policy to another
Firewall and IPsec rules with the same rule properties can be duplicated to simplify the task of re-creating them within different policy stores.
To copy the previously created rule from one policy store to another, the associated objects must also be copied separately. There's no need to copy associated firewall filters. You can query rules to be copied in the same way as other cmdlets.
Copying individual rules is a task that isn't possible through the Netsh interface. Here's how you can accomplish it with Windows PowerShell.
To handle errors in your Windows PowerShell scripts, you can use the *–ErrorAction* parameter. This parameter is especially useful with the **Remove** cmdlets. If you want to remove a particular rule, you'll notice that it fails if the rule isn't found. When rules are being removed, if the rule isn’t already there, it's acceptable to ignore that error. In this case, you can do the following to suppress any “rule not found” errors during the remove operation.
Windows PowerShell
To handle errors in your Windows PowerShell scripts, you can use the *-ErrorAction* parameter. This parameter is especially useful with the **Remove** cmdlets. If you want to remove a particular rule, you'll notice that it fails if the rule isn't found. When rules are being removed, if the rule isn't already there, it's acceptable to ignore that error. In this case, you can do the following to suppress any "rule not found" errors during the remove operation.
The use of wildcards can also suppress errors, but they could potentially match rules that you didn't intend to remove. These wildcards can be a useful shortcut, but should only be used if you know there aren’t any extra rules that will be accidentally deleted. So the following cmdlet will also remove the rule, suppressing any “not found” errors.
Windows PowerShell
The use of wildcards can also suppress errors, but they could potentially match rules that you didn't intend to remove. These wildcards can be a useful shortcut, but should only be used if you know there aren't any extra rules that will be accidentally deleted. So the following cmdlet will also remove the rule, suppressing any "not found" errors.
The following Windows PowerShell commands are useful in the update cycle of a deployment phase.
To allow you to view all the IPsec rules in a particular store, you can use the following commands. In Netsh, this command doesn't show rules where profile=domain,public or profile=domain,private. It only shows rules that have the single entry domain that is included in the rule. The following command examples will show the IPsec rules in all profiles.
**Netsh**
``` syntax
```cmd
netsh advfirewall consec show rule name=all
```
Windows PowerShell
```powershell
Show-NetIPsecRule –PolicyStore ActiveStore
Show-NetIPsecRule -PolicyStore ActiveStore
```
You can monitor main mode security associations for information such as which peers are currently connected to the device and which protection suite is used to form the security associations.
Use the following cmdlet to view existing main mode rules and their security associations:
**Netsh**
``` syntax
```cmd
netsh advfirewall monitor show mmsa all
```
Windows PowerShell
```powershell
Get-NetIPsecMainModeSA
```
### Find the source GPO of a rule
To view the properties of a particular rule or group of rules, you query for the rule. When a query returns fields that are specified as **NotConfigured**, you can determine which policy store a rule originates from.
For objects that come from a GPO (the *–PolicyStoreSourceType* parameter is specified as **GroupPolicy** in the **Show** command), if *–TracePolicyStore* is passed, the name of the GPO is found and returned in the **PolicyStoreSource** field.
Windows PowerShell
For objects that come from a GPO (the *-PolicyStoreSourceType* parameter is specified as **GroupPolicy** in the **Show** command), if *-TracePolicyStore* is passed, the name of the GPO is found and returned in the **PolicyStoreSource** field.
It's important to note that the revealed sources don't contain a domain name.
### Deploy a basic domain isolation policy
IPsec can be used to isolate domain members from non-domain members. Domain isolation uses IPsec authentication to require that the domain-joined devices positively establish the identities of the communicating devices to improve security of an organization. One or more features of IPsec can be used to secure traffic with an IPsec rule object.
To implement domain isolation on your network, the devices in the domain receive IPsec rules that block unsolicited inbound network traffic that isn't protected by IPsec. Here we create an IPsec rule that requires authentication by domain members. Through this authentication, you can isolate domain-joined devices from devices that aren't joined to a domain. In the following examples, Kerberos authentication is required for inbound traffic and requested for outbound traffic.
**Netsh**
``` syntax
```cmd
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
The following command creates an IPsec tunnel that routes traffic from a private network (192.168.0.0/16) through an interface on the local device (1.1.1.1) attached to a public network to a second device through its public interface (2.2.2.2) to another private network (192.157.0.0/16). All traffic through the tunnel is checked for integrity by using ESP/SHA1, and it's encrypted by using ESP/DES3.
**Netsh**
``` syntax
```cmd
netsh advfirewall consec add rule name="Tunnel from 192.168.0.0/16 to 192.157.0.0/16" mode=tunnel endpoint1=192.168.0.0/16 endpoint2=192.157.0.0/16 localtunnelendpoint=1.1.1.1 remotetunnelendpoint=2.2.2.2 action=requireinrequireout qmsecmethods=esp:sha1-3des
In situations where only secure traffic can be allowed through the Windows Defender Firewall, a combination of manually configured firewall and IPsec rules are necessary. The firewall rules determine the level of security for allowed packets, and the underlying IPsec rules secure the traffic. The scenarios can be accomplished in Windows PowerShell and in Netsh, with many similarities in deployment.
### Create a secure firewall rule (allow if secure)
Configuring firewalls rule to allow connections if they're secure requires the corresponding traffic to be authenticated and integrity protected, and then optionally encrypted by IPsec.
The following example creates a firewall rule that requires traffic to be authenticated. The command permits inbound Telnet network traffic only if the connection from the remote device is authenticated by using a separate IPsec rule.
The following command creates an IPsec rule that requires a first (computer) authentication and then attempts an optional second (user) authentication. Creating this rule secures and allows the traffic through the firewall rule requirements for the messenger program.
**Netsh**
``` syntax
```cmd
netsh advfirewall consec add rule name="Authenticate Both Computer and User" endpoint1=any endpoint2=any action=requireinrequireout auth1=computerkerb,computerntlm auth2=userkerb,userntlm,anonymous
New-NetIPSecRule -DisplayName "Authenticate Both Computer and User" -InboundSecurity Require -OutboundSecurity Require -Phase1AuthSet $P1Auth.Name -Phase2AuthSet $P2Auth.Name
```
### Isolate a server by requiring encryption and group membership
To improve the security of the devices in an organization, you can deploy domain isolation in which domain-members are restricted. They require authentication when communicating among each other and reject non-authenticated inbound connections. To improve the security of servers with sensitive data, this data must be protected by allowing access only to a subset of devices within the enterprise domain.
IPsec can provide this extra layer of protection by isolating the server. In server isolation, sensitive data access is restricted to users and devices with legitimate business need, and the data is additionally encrypted to prevent eavesdropping.
### Create a firewall rule that requires group membership and encryption
To deploy server isolation, we layer a firewall rule that restricts traffic to authorized users or devices on the IPsec rule that enforces authentication.
The following firewall rule allows Telnet traffic from user accounts that are members of a custom group called “Authorized to Access Server.” This access can additionally be restricted based on the device, user, or both by specifying the restriction parameters.
A Security Descriptor Definition Language (SDDL) string is created by extending a user or group’s security identifier (SID). For more information about finding a group’s SID, see: [Finding the SID for a group account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)#bkmk_FINDSID).
The following firewall rule allows Telnet traffic from user accounts that are members of a custom group called "Authorized to Access Server." This access can additionally be restricted based on the device, user, or both by specifying the restriction parameters.
A Security Descriptor Definition Language (SDDL) string is created by extending a user or group's security identifier (SID). For more information about finding a group's SID, see: [Finding the SID for a group account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)#bkmk_FINDSID).
Restricting access to a group allows administrations to extend strong authentication support through Windows Defender Firewall and/or IPsec policies.
The following example shows you how to create an SDDL string that represents security groups.
For more information about how to create security groups or how to determine the SDDL string, see [Working with SIDs](/previous-versions/windows/it-pro/windows-powershell-1.0/ff730940(v=technet.10)).
Telnet is an application that doesn't provide encryption. This application can send data, such as names and passwords, over the network. This data can be intercepted by malicious users. If an administrator would like to allow the use of Telnet, but protect the traffic, a firewall rule that requires IPsec encryption can be created. This firewall rule is necessary so that the administrator can be certain that when this application is used, all of the traffic sent or received by this port is encrypted. If IPsec fails to authorize the connection, no traffic is allowed from this application.
In this example, we allow only authenticated and encrypted inbound Telnet traffic from a specified secure user group through the creation of the following firewall rule.
**Netsh**
``` syntax
```cmd
netsh advfirewall set store gpo=domain.contoso.com\Server_Isolation
netsh advfirewall firewall add rule name=“Allow Encrypted Inbound Telnet to Group Members Only” program=%SystemRoot%\System32\tlntsvr.exe protocol=TCP dir=in action=allow localport=23 security=authenc rmtusrgrp ="D:(A;;CC;;; S-1-5-21-2329867823-2610410949-1491576313-1735)"
netsh advfirewall firewall add rule name="Allow Encrypted Inbound Telnet to Group Members Only" program=%SystemRoot%\System32\tlntsvr.exe protocol=TCP dir=in action=allow localport=23 security=authenc rmtusrgrp ="D:(A;;CC;;; S-1-5-21-2329867823-2610410949-1491576313-1735)"
```
Windows PowerShell
```powershell
New-NetFirewallRule -DisplayName "Allow Encrypted Inbound Telnet to Group Members Only" -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -Direction Inbound -Action Allow -LocalPort23 -Authentication Required -Encryption Required –RemoteUser $secureUserGroup –PolicyStore domain.contoso.com\Server_Isolation
New-NetFirewallRule -DisplayName "Allow Encrypted Inbound Telnet to Group Members Only" -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -Direction Inbound -Action Allow -LocalPort23 -Authentication Required -Encryption Required -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\Server_Isolation
```
### Endpoint security enforcement
The previous example showed end to end security for a particular application. In situations where endpoint security is required for many applications, having a firewall rule per application can be cumbersome and difficult to manage. Authorization can override the per-rule basis and be done at the IPsec layer.
In this example, we set the global IPsec setting to only allow transport mode traffic to come from an authorized user group with the following cmdlet. Consult the previous examples for working with security groups.
Authenticated bypass allows traffic from a specified trusted device or user to override firewall block rules. This override is helpful when an administrator wants to use scanning servers to monitor and update devices without the need to use port-level exceptions. For more information, see [How to enable authenticated firewall bypass](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)).
In this example, we assume that a blocking firewall rule exists. This example permits any network traffic on any port from any IP address to override the block rule, if the traffic is authenticated as originating from a device or user account that is a member of the specified device or user security group.
**Netsh**
``` syntax
```cmd
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Paolo Matarazzo