resolved conflicts

windows/security/operating-system-security/network-security/toc.yml

@@ -1,40 +1,17 @@
 items:
-- name: Transport layer security (TLS)
-  href: /windows-server/security/tls/tls-ssl-schannel-ssp-overview
-- name: WiFi Security
-  href: https://support.microsoft.com/windows/faster-and-more-secure-wi-fi-in-windows-26177a28-38ed-1a8e-7eca-66f24dc63f09
-- name: Windows Firewall
-  href: ../../threat-protection/windows-firewall/windows-firewall-with-advanced-security.md
-- name: Virtual Private Network (VPN)
-  href: ../../identity-protection/vpn/vpn-guide.md
-  items:
-  - name: VPN connection types
-    href: ../../identity-protection/vpn/vpn-connection-type.md
-  - name: VPN routing decisions
-    href: ../../identity-protection/vpn/vpn-routing.md
-  - name: VPN authentication options
-    href: ../../identity-protection/vpn/vpn-authentication.md
-  - name: VPN and conditional access
-    href: ../../identity-protection/vpn/vpn-conditional-access.md
-  - name: VPN name resolution
-    href: ../../identity-protection/vpn/vpn-name-resolution.md
-  - name: VPN auto-triggered profile options
-    href: ../../identity-protection/vpn/vpn-auto-trigger-profile.md
-  - name: VPN security features
-    href: ../../identity-protection/vpn/vpn-security-features.md
-  - name: VPN profile options
-    href: ../../identity-protection/vpn/vpn-profile-options.md
-  - name: How to configure Diffie Hellman protocol over IKEv2 VPN connections
-    href: ../../identity-protection/vpn/how-to-configure-diffie-hellman-protocol-over-ikev2-vpn-connections.md
-  - name: How to use single sign-on (SSO) over VPN and Wi-Fi connections
-    href: ../../identity-protection/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
-  - name: Optimizing Office 365 traffic with the Windows VPN client
-    href: ../../identity-protection/vpn/vpn-office-365-optimization.md
-- name: Always On VPN
-  href: /windows-server/remote/remote-access/vpn/always-on-vpn/
-- name: Direct Access
-  href: /windows-server/remote/remote-access/directaccess/directaccess
-- name: Server Message Block (SMB) file service
-  href: /windows-server/storage/file-server/file-server-smb-overview
-- name: Server Message Block Direct (SMB Direct)
-  href: /windows-server/storage/file-server/smb-direct
+  - name: Transport layer security (TLS) 🔗
+    href: /windows-server/security/tls/tls-ssl-schannel-ssp-overview
+  - name: WiFi Security
+    href: https://support.microsoft.com/windows/faster-and-more-secure-wi-fi-in-windows-26177a28-38ed-1a8e-7eca-66f24dc63f09
+  - name: Windows Firewall 🔗
+    href: windows-firewall/windows-firewall-with-advanced-security.md
+  - name: Virtual Private Network (VPN)
+    href: vpn/toc.yml
+  - name: Always On VPN 🔗
+    href: /windows-server/remote/remote-access/vpn/always-on-vpn/
+  - name: Direct Access 🔗
+    href: /windows-server/remote/remote-access/directaccess/directaccess
+  - name: Server Message Block (SMB) file service 🔗
+    href: /windows-server/storage/file-server/file-server-smb-overview
+  - name: Server Message Block Direct (SMB Direct) 🔗
+    href: /windows-server/storage/file-server/smb-direct

windows/security/operating-system-security/network-security/vpn/how-to-configure-diffie-hellman-protocol-over-ikev2-vpn-connections.md

@@ -0,0 +1,36 @@
+---
+title: How to configure Diffie Hellman protocol over IKEv2 VPN connections
+description: Learn how to update the Diffie Hellman configuration of VPN servers and clients by running VPN cmdlets to secure connections.
+ms.date: 09/23/2021
+ms.topic: how-to
+---
+
+# How to configure Diffie Hellman protocol over IKEv2 VPN connections
+
+In IKEv2 VPN connections, the default configuration for Diffie Hellman group is Group 2, which is not secure for IKE exchanges.
+
+To secure the connections, update the configuration of VPN servers and clients by running VPN cmdlets.
+
+## VPN server
+
+For VPN servers that run Windows Server 2012 R2 or later, you need to run [Set-VpnServerConfiguration](/powershell/module/remoteaccess/set-vpnserverconfiguration?view=win10-ps&preserve-view=true) to configure the tunnel type. This makes all IKE exchanges on IKEv2 tunnel use the secure configuration.
+
+```powershell
+Set-VpnServerConfiguration -TunnelType IKEv2 -CustomPolicy
+```
+
+On an earlier version of Windows Server, run [Set-VpnServerIPsecConfiguration](/previous-versions/windows/powershell-scripting/hh918373(v=wps.620)). Since `Set-VpnServerIPsecConfiguration` doesn't have `-TunnelType`, the configuration applies to all tunnel types on the server.
+
+```powershell
+Set-VpnServerIPsecConfiguration -CustomPolicy
+```
+
+## VPN client 
+
+For VPN client, you need to configure each VPN connection. 
+For example, run [Set-VpnConnectionIPsecConfiguration (version 4.0)](/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps&preserve-view=true) and specify the name of the connection:
+
+
+```powershell
+Set-VpnConnectionIPsecConfiguration -ConnectionName <String>
+```

windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md

@@ -0,0 +1,94 @@
+---
+title: How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
+description: Explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections.
+ms.date: 12/28/2022
+ms.topic: how-to
+---
+
+# How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
+
+This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections. The following scenarios are typically used:
+
+- Connecting to a network using Wi-Fi or VPN
+- Use credentials for Wi-Fi or VPN authentication to also authenticate requests to access domain resources, without being prompted for domain credentials
+
+For example, you want to connect to a corporate network and access an internal website that requires Windows integrated authentication.
+
+The credentials that are used for the connection authentication are placed in *Credential Manager* as the default credentials for the **logon session**. Credential Manager stores credentials that can be used for specific domain resources. These are based on the target name of the resource:
+
+- For VPN, the VPN stack saves its credential as the **session default**
+- For WiFi, Extensible Authentication Protocol (EAP) provides support
+
+The credentials are placed in Credential Manager as a *session credential*:
+
+- A *session credential* implies that it is valid for the current user session
+- The credentials are cleaned up when the WiFi or VPN connection is disconnected
+
+> [!NOTE]
+> In Windows 10, version 21H2 and later, the *session credential* is not visible in Credential Manager.
+
+For example, if someone using Microsoft Edge tries to access a domain resource, Microsoft Edge has the right Enterprise Authentication capability. This allows [WinInet](/windows/win32/wininet/wininet-reference) to release the credentials that it gets from Credential Manager to the SSP that is requesting it.
+For more information about the Enterprise Authentication capability, see [App capability declarations](/windows/uwp/packaging/app-capability-declarations).
+
+The local security authority will look at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application.
+If the app isn't a UWP, it doesn't matter.
+But, if the application is a UWP app, it will evaluate at the device capability for Enterprise Authentication.
+If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released.
+This behavior helps prevent credentials from being misused by untrusted third parties.
+
+## Intranet zone
+
+For the Intranet zone, by default it only allows single-label names, such as *http://finance*.
+If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the [Registry CSP](/windows/client-management/mdm/registry-csp).
+
+### Setting the ZoneMap
+
+The ZoneMap is controlled using a registry that can be set through MDM.
+By default, single-label names such as *http://finance* are already in the intranet zone.
+For multi-label names, such as *http://finance.net*, the ZoneMap needs to be updated.
+
+## MDM Policy
+
+OMA URI example:
+
+`./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-2781/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/<domain name>` as an `Integer` value of `1` for each of the domains that you want to SSO into from your device. This adds the specified domains to the Intranet Zone of the Microsoft Edge browser.
+
+## Credential requirements
+
+For VPN, the following types of credentials will be added to credential manager after authentication:
+
+- Username and password
+- Certificate-based authentication:
+  - TPM Key Storage Provider (KSP) Certificate
+  - Software Key Storage Provider (KSP) Certificates
+  - Smart Card Certificate
+  - Windows Hello for Business Certificate
+
+The username should also include a domain that can be reached over the connection (VPN or WiFi).
+
+## User certificate templates
+
+If the credentials are certificate-based, then the elements in the following table need to be configured for the certificate templates to ensure they can also be used for Kerberos client authentication.
+
+| Template element | Configuration |
+|------------------|---------------|
+| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
+| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
+| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
+| EnhancedKeyUsage | One or more of the following EKUs is required: </br><ul><li>Client Authentication (for the VPN)</li><li>EAP Filtering OID (for Windows Hello for Business)</li><li>SmartCardLogon (for Azure AD-joined devices)</li></ul>If the domain controllers require smart card EKU either:<ul><li>SmartCardLogon</li><li>id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) </li></ul>Otherwise:</br><ul><li>TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)</li></ul> |
+
+## NDES server configuration
+
+The NDES server is required to be configured so that incoming SCEP requests can be mapped to the correct template to be used.
+For more information, see [Configure certificate infrastructure for SCEP](/mem/intune/protect/certificates-scep-configure).
+
+## Active Directory requirements
+
+You need IP connectivity to a DNS server and domain controller over the network interface so that authentication can succeed as well.
+
+Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones are not domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.
+
+Domain controllers must be using certificates based on the updated KDC certificate template Kerberos Authentication.
+This requires that all authenticating domain controllers run Windows Server 2016, or you'll need to enable strict KDC validation on domain controllers that run previous versions of Windows Server.
+
+For more information, see [Enabling Strict KDC Validation in Windows Kerberos](https://www.microsoft.com/download/details.aspx?id=6382).

windows/security/operating-system-security/network-security/vpn/toc.yml

@@ -0,0 +1,25 @@
+items:
+  - name: Overview
+    href: vpn-guide.md
+  - name: VPN connection types
+    href: vpn-connection-type.md
+  - name: VPN routing decisions
+    href: vpn-routing.md
+  - name: VPN authentication options
+    href: vpn-authentication.md
+  - name: VPN and conditional access
+    href: vpn-conditional-access.md
+  - name: VPN name resolution
+    href: vpn-name-resolution.md
+  - name: VPN auto-triggered profile options
+    href: vpn-auto-trigger-profile.md
+  - name: VPN security features
+    href: vpn-security-features.md
+  - name: VPN profile options
+    href: vpn-profile-options.md
+  - name: How to configure Diffie Hellman protocol over IKEv2 VPN connections
+    href: how-to-configure-diffie-hellman-protocol-over-ikev2-vpn-connections.md
+  - name: How to use single sign-on (SSO) over VPN and Wi-Fi connections
+    href: how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
+  - name: Optimizing Office 365 traffic with the Windows VPN client
+    href: vpn-office-365-optimization.md

windows/security/operating-system-security/network-security/vpn/vpn-authentication.md

@@ -0,0 +1,92 @@
+---
+title: VPN authentication options 
+description: Learn about the EAP authentication methods that Windows supports in VPNs to provide secure authentication using username/password and certificate-based methods.
+ms.date: 09/23/2021
+ms.topic: conceptual
+---
+
+# VPN authentication options
+
+In addition to older and less-secure password-based authentication methods (which should be avoided), the built-in VPN solution uses Extensible Authentication Protocol (EAP) to provide secure authentication using both user name and password, and certificate-based methods. You can only configure EAP-based authentication if you select a built-in VPN type (IKEv2, L2TP, PPTP or Automatic).
+
+Windows supports a number of EAP authentication methods. 
+
+- EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MSCHAPv2):
+  - User name and password authentication
+  - Winlogon credentials - can specify authentication with computer sign-in credentials
+
+- EAP-Transport Layer Security (EAP-TLS):
+  - Supports the following types of certificate authentication:
+    - Certificate with keys in the software Key Storage Provider (KSP)
+    - Certificate with keys in Trusted Platform Module (TPM) KSP
+    - Smart card certificates
+    - Windows Hello for Business certificate
+
+  - Certificate filtering:
+    - Certificate filtering can be enabled to search for a particular certificate to use to authenticate with
+    - Filtering can be Issuer-based or extended key usage (EKU)-based
+
+  - Server validation - with TLS, server validation can be toggled on or off:
+    - Server name - specify the server to validate
+    - Server certificate - trusted root certificate to validate the server
+    - Notification - specify if the user should get a notification asking whether to trust the server or not
+
+- [Protected Extensible Authentication Protocol (PEAP)](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754179(v=ws.11)):
+  - Server validation - with PEAP, server validation can be toggled on or off:
+    - Server name - specify the server to validate
+    - Server certificate - trusted root certificate to validate the server
+    - Notification - specify if the user should get a notification asking whether to trust the server or not
+
+  - Inner method - the outer method creates a secure tunnel inside while the inner method is used to complete the authentication:
+    - EAP-MSCHAPv2
+    - EAP-TLS
+
+  - Fast Reconnect: reduces the delay between an authentication request by a client and the response by the Network Policy Server (NPS) or other Remote Authentication Dial-in User Service (RADIUS) server. This reduces resource requirements for both client and server, and minimizes the number of times that users are prompted for credentials.
+
+  - [Cryptobinding](/openspecs/windows_protocols/ms-peap/757a16c7-0826-4ba9-bb71-8c3f1339e937): By deriving and exchanging values from the PEAP phase 1 key material (**Tunnel Key**) and from the PEAP phase 2 inner EAP method key material (**Inner Session Key**), it is possible to prove that the two authentications terminate at the same two entities (PEAP peer and PEAP server). This process, termed "cryptobinding", is used to protect the PEAP negotiation against "Man in the Middle" attacks.
+
+- Tunneled Transport Layer Security (TTLS)
+  - Inner method
+    - Non-EAP
+      - Password Authentication Protocol (PAP)
+      - CHAP
+      - MSCHAP
+      - MSCHAPv2
+    - EAP
+      - MSCHAPv2
+      - TLS
+  - Server validation: in TTLS, the server must be validated. The following can be configured:
+    - Server name
+    - Trusted root certificate for server certificate
+    - Whether there should be a server validation notification
+
+For a UWP VPN plug-in, the app vendor controls the authentication method to be used. The following credential types can be used:
+
+- Smart card
+- Certificate
+- Windows Hello for Business
+- User name and password
+- One-time password
+- Custom credential type
+
+## Configure authentication
+
+See [EAP configuration](/windows/client-management/mdm/eap-configuration) for EAP XML configuration. 
+
+>[!NOTE]
+>To configure Windows Hello for Business authentication, follow the steps in [EAP configuration](/windows/client-management/mdm/eap-configuration) to create a smart card certificate. [Learn more about Windows Hello for Business.](../../../identity-protection/hello-for-business/hello-identity-verification.md).
+
+The following image shows the field for EAP XML in a Microsoft Intune VPN profile. The EAP XML field only appears when you select a built-in connection type (automatic, IKEv2, L2TP, PPTP).
+
+:::image type="content" source="images/vpn-eap-xml.png" alt-text="EAP XML configuration in Intune profile.":::
+
+## Related topics
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN security features](vpn-security-features.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/vpn/vpn-auto-trigger-profile.md

@@ -0,0 +1,90 @@
+---
+title: VPN auto-triggered profile options
+description: With auto-triggered VPN profile options, Windows can automatically establish a VPN connection based on IT admin-defined rules. Learn about the types of auto-trigger rules that you can create for VPN connections.
+ms.date: 05/24/2023
+ms.topic: conceptual
+---
+
+# VPN auto-triggered profile options
+
+Windows can use different features to auto-trigger VPN, avoiding users to manually connect when VPN is needed to access necessary resources. There are three different types of auto-trigger rules:
+
+- Application trigger
+- Name-based trigger
+- Always On
+
+> [!NOTE]
+> Auto-triggered VPN connections won't work if **Folder Redirection** for **AppData** is enabled. Either Folder Redirection for AppData must be disabled, or the auto-triggered VPN profile must be deployed in SYSTEM context, which changes the path to where the *rasphone.pbk* file is stored.
+
+## Application trigger
+
+VPN profiles can be configured to automatically connect on the execution of certain applications:
+
+- You can configure desktop or Universal Windows Platform (UWP) apps to trigger a VPN connection
+- You can configure per-app VPN and specify traffic rules for each app
+
+> [!NOTE]
+> The app identifier for a desktop app is a file path. The app identifier for a UWP app is a package family name.
+>
+> [Find a package family name (PFN) for per-app VPN configuration](/mem/configmgr/protect/deploy-use/find-a-pfn-for-per-app-vpn)
+
+For more information, see [Traffic filters](vpn-security-features.md#traffic-filters).
+
+## Name-based trigger
+
+You can configure a domain name-based rule so that a specific domain name triggers the VPN connection.\ 
+Name-based auto-trigger can be configured using the `VPNv2/<ProfileName>/DomainNameInformationList/dniRowId/AutoTrigger` setting in the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
+
+There are four types of name-based triggers:
+
+- Short name: for example, if *HRweb* is configured as a trigger, and the stack sees a DNS resolution request for *HRweb*, the VPN triggers
+- Fully qualified domain name (FQDN): for example, if *HRweb.corp.contoso.com* is configured as a trigger, and the stack sees a DNS resolution request for *HRweb.corp.contoso.com*, the VPN triggers
+- Suffix: for example, if *.corp.contoso.com* is configured as a trigger, and the stack sees a DNS resolution request with a matching suffix (such as *HRweb.corp.contoso.com*), the VPN triggers. For any short name resolution, VPN triggers, and the DNS servers are queried for the *<ShortName\>.corp.contoso.com*
+- All: if used, all DNS resolution triggers VPN
+
+## Always On
+
+Always On is a Windows feature that enables the active VPN profile to connect automatically on the following triggers:
+
+- User sign-in
+- Network change
+- Device screen on
+
+When the trigger occurs, VPN tries to connect. If an error occurs, or any user input is needed, the user sees a toast notification for more interaction.
+
+When a device has multiple profiles with Always On triggers, the user can specify the active profile in **Settings > Network & Internet > VPN > <VPN profile\>** by selecting the **Let apps automatically use this VPN connection** checkbox. By default, the first MDM-configured profile is marked as **Active**. Devices with multiple users have the same restriction: only one profile, and therefore only one user, is able to use the Always On triggers.
+
+## Preserving user Always On preference
+
+Another Windows feature is to preserve a user's Always On preference. If a user manually unchecks the **Connect automatically** checkbox, Windows remembers the user preference for the profile name by adding the profile name to the registry value *AutoTriggerDisabledProfilesList*.  
+
+If a management tool removes or adds the same profile name back and set **AlwaysOn** to **true**, Windows doesn't check the box if the profile name exists in the following registry value, in order to preserve user preference.
+
+**Key:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Config`\
+**Value:** `AutoTriggerDisabledProfilesList`\
+**Type:** `REG_MULTI_SZ`
+
+## Trusted network detection
+
+The **Trusted network detection** feature configures the VPN so that connection isn't triggered when a device is on a trusted network. To configure Trusted network detection, you must provide a list of DNS suffixes. The VPN stack verifies the network name of the physical interface connection profile: if it matches any of the suffixes configured in the list and the network is private or provisioned by MDM, then VPN doesn't trigger.
+
+Trusted network detection can be configured using the `VPNv2/<ProfileName>/TrustedNetworkDetection` setting in the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp).
+
+## Configure app-triggered VPN
+
+See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
+
+The following image shows associating apps to a VPN connection in a VPN Profile configuration policy using Microsoft Intune.
+
+:::image type="content" source="images/vpn-app-trigger.png" alt-text="Creation of VPN profile in Intune: application association options." lightbox="images/vpn-app-trigger.png":::
+
+## Related articles
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN security features](vpn-security-features.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/vpn/vpn-conditional-access.md

@@ -0,0 +1,102 @@
+---
+title: VPN and conditional access
+description: Learn how to integrate the VPN client with the Conditional Access platform, and how to create access rules for Azure Active Directory (Azure AD) connected apps.
+ms.date: 05/23/2023
+ms.topic: conceptual
+---
+
+# VPN and conditional access
+
+The VPN client is now able to integrate with the cloud-based Conditional Access Platform to provide a device compliance option for remote clients. Conditional Access is a policy-based evaluation engine that lets you create access rules for any Azure Active Directory (Azure AD) connected application.  
+
+>[!NOTE]
+>Conditional Access is an Azure AD Premium feature.
+
+Conditional Access Platform components used for Device Compliance include the following cloud-based services:
+
+- [Conditional Access Framework](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
+- [Azure AD Connect Health](/azure/active-directory/connect-health/active-directory-aadconnect-health)
+- [Windows Health Attestation Service](../../../threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md#device-health-attestation) (optional)
+- Azure AD Certificate Authority - It is a requirement that the client certificate used for the cloud-based device compliance solution be issued by an Azure Active Directory-based Certificate Authority (CA). An Azure AD CA is essentially a mini-CA cloud tenant in Azure. The Azure AD CA cannot be configured as part of an on-premises Enterprise CA. 
+See also [Always On VPN deployment for Windows Server and Windows 10](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy).
+- Azure AD-issued short-lived certificates - When a VPN connection attempt is made, the Azure AD Token Broker on the local device communicates with Azure Active Directory, which then checks for health based on compliance rules. If compliant, Azure AD sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used. When the client reconnects and determines that the certificate has expired, the client will again check with Azure AD for health validation before a new certificate is issued.
+- [Microsoft Intune device compliance policies](/mem/intune/protect/device-compliance-get-started) - Cloud-based device compliance leverages Microsoft Intune Compliance Policies, which are capable of querying the device state and define compliance rules for the following, among other things.
+  - Antivirus status
+  - Auto-update status and update compliance
+  - Password policy compliance
+  - Encryption compliance
+  - Device health attestation state (validated against attestation service after query)
+
+The following client-side components are also required:
+
+- [HealthAttestation Configuration Service Provider (CSP)](/windows/client-management/mdm/healthattestation-csp)
+- [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) DeviceCompliance node settings
+- Trusted Platform Module (TPM)
+
+## VPN device compliance
+
+At this time, the Azure AD certificates issued to users do not contain a CRL Distribution Point (CDP) and are not suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the <SSO> section.
+
+Server-side infrastructure requirements to support VPN device compliance include:
+
+- The VPN server should be configured for certificate authentication.
+- The VPN server should trust the tenant-specific Azure AD CA.
+- For client access using Kerberos/NTLM, a domain-trusted certificate is deployed to the client device and is configured to be used for single sign-on (SSO).
+
+After the server side is set up, VPN admins can add the policy settings for conditional access to the VPN profile using the VPNv2 DeviceCompliance node.
+
+Two client-side configuration service providers are leveraged for VPN device compliance.
+
+- VPNv2 CSP DeviceCompliance settings:
+  - **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD.
+  - **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication.
+  - **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication.
+  - **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication.
+  - **Sso/Eku**: comma-separated list of extended key usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication.
+- HealthAttestation CSP (not a requirement) - functions performed by the HealthAttestation CSP include:
+  - Collects TPM data used to verify health states
+  - Forwards the data to the Health Attestation Service (HAS)
+  - Provisions the Health Attestation Certificate received from the HAS
+  - Upon request, forward the Health Attestation Certificate (received from HAS) and related runtime information to the MDM server for verification
+
+> [!NOTE]
+> It's required that certificates used for obtaining Kerberos tickets to be issued from an on-premises CA, and that SSO to be enabled in the user's VPN profile. This will enable the user to access on-premises resources.
+> In the case of AzureAD-only joined devices (not hybrid joined devices), if the user certificate issued by the on-premises CA has the user UPN from AzureAD in Subject and SAN (Subject Alternative Name), the VPN profile must be modified to ensure that the client does not cache the credentials used for VPN authentication. To do this, after deploying the VPN profile to the client, modify the *Rasphone.pbk* on the client by changing the entry **UseRasCredentials** from 1 (default) to 0 (zero).
+
+## Client connection flow
+
+The VPN client side connection flow works as follows:
+
+![Device compliance workflow when VPN client attempts to connect.](images/vpn-device-compliance.png)
+
+When a VPNv2 Profile is configured with \<DeviceCompliance> \<Enabled>true<\/Enabled> the VPN client uses this connection flow:
+
+1. The VPN client calls into Windows 10's or Windows 11's Azure AD Token Broker, identifying itself as a VPN client.
+1. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies.
+1. If compliant, Azure AD requests a short-lived certificate.
+1. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection  processing.
+1. The VPN client uses the Azure AD-issued certificate to authenticate with the VPN server.
+
+## Configure conditional access
+
+See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration. 
+
+## Learn more about Conditional Access and Azure AD Health
+
+- [Azure Active Directory conditional access](/azure/active-directory/conditional-access/overview)
+- [Getting started with Azure Active Directory Conditional Access](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
+- [Control the health of Windows devices](../../../threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)
+- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 1)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
+- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 2)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-2)
+- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 3)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-3)
+- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 4)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-4)
+
+## Related topics
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN security features](vpn-security-features.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/vpn/vpn-connection-type.md

@@ -0,0 +1,57 @@
+---
+title: VPN connection types (Windows 10 and Windows 11)
+description: Learn about Windows VPN platform clients and the VPN connection-type features that can be configured.
+ms.date: 05/24/2022
+ms.topic: conceptual
+---
+
+# VPN connection types
+
+VPNs are point-to-point connections across a private or public network, like the Internet. A VPN client uses special TCP/IP or UDP-based protocols, called *tunneling protocols*, to make a virtual call to a virtual port on a VPN server. In a typical VPN deployment, a client initiates a virtual point-to-point connection to a remote access server over the Internet. The remote access server answers the call, authenticates the caller, and transfers data between the VPN client and the organization's private network.
+
+There are many options for VPN clients. In Windows, the built-in plug-in and the Universal Windows Platform (UWP) VPN plug-in platform are built on top of the Windows VPN platform. This article focuses on the Windows VPN platform clients and the features that can be configured.
+
+![VPN connection types.](images/vpn-connection.png)
+
+## Built-in VPN client
+
+Tunneling protocols:
+- [Internet Key Exchange version 2 (IKEv2)](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687731(v=ws.10)): configure the IPsec/IKE tunnel cryptographic properties using the **Cryptography Suite** setting in the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
+- [L2TP](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687761(v=ws.10)): L2TP with pre-shared key (PSK) authentication can be configured using the **L2tpPsk** setting in the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp).
+- [PPTP](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687676(v=ws.10))
+- [SSTP](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687819(v=ws.10)): SSTP can't be configured using MDM, but it's one of the protocols attempted in the **Automatic** option
+    > [!NOTE]
+    > When a VPN plug-in is used, the adapter will be listed as an SSTP adapter, even though the VPN protocol used is the plug-in's protocol.
+
+- Automatic: the **Automatic** option means that the device tries each of the built-in tunneling protocols until one succeeds. It attempts from most secure to least secure. Configure **Automatic** for the **NativeProtocolType** setting in the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp).
+
+## Universal Windows Platform VPN plug-in
+
+Using the UWP platform, third-party VPN providers can create app-containerized plug-ins using WinRT APIs, eliminating the complexity and problems often associated with writing to system-level drivers.
+
+There are many Universal Windows Platform VPN applications, such as Pulse Secure, Cisco AnyConnect, F5 Access, Sonicwall Mobile Connect, and Check Point Capsule. If you want to use a UWP VPN plug-in, work with your vendor for any custom settings needed to configure your VPN solution.
+
+## Configure connection type
+
+See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
+
+The following image shows connection options in a VPN Profile configuration policy using Microsoft Intune:
+
+> [!div class="mx-imgBorder"]
+> ![Available connection types.](images/vpn-connection-intune.png)
+
+In Intune, you can also include custom XML for third-party plug-in profiles:
+
+> [!div class="mx-imgBorder"]
+> ![Custom XML.](images/vpn-custom-xml-intune.png)
+
+## Related articles
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN security features](vpn-security-features.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/vpn/vpn-guide.md

@@ -0,0 +1,34 @@
+---
+title: Windows VPN technical guide
+description: Learn how to plan and configure Windows devices for your organization's VPN solution.
+ms.date: 05/24/2023
+ms.topic: conceptual
+---
+
+# Windows VPN technical guide
+
+This guide walks you through the decisions to make for Windows clients in your organization's VPN solution, and how to configure your devices. This guide references the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp) and provides mobile device management (MDM) configuration instructions using Microsoft Intune.
+
+To create a Windows VPN device configuration profile see: [Windows device settings to add VPN connections using Intune](/mem/intune/configuration/vpn-settings-windows-10).
+
+> [!NOTE]
+> This guide does not explain server deployment.
+
+[!INCLUDE [virtual-private-network-vpn](../../../../../includes/licensing/virtual-private-network-vpn.md)]
+
+## In this guide
+
+| Article | Description  |
+| --- | --- |
+| [VPN connection types](vpn-connection-type.md) | Select a VPN client and tunneling protocol |
+| [VPN routing decisions](vpn-routing.md)  | Choose between split tunnel and force tunnel configuration |
+| [VPN authentication options](vpn-authentication.md)  | Select a method for Extensible Authentication Protocol (EAP) authentication. |
+| [VPN and conditional access](vpn-conditional-access.md)  | Use Azure Active Directory policy evaluation to set access policies for VPN connections. |
+| [VPN name resolution](vpn-name-resolution.md)  | Decide how name resolution should work |
+| [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)  | Set a VPN profile to connect automatically by app or by name, to be "always on", and to not trigger VPN on trusted networks |
+| [VPN security features](vpn-security-features.md)  | Configure traffic filtering, connect a VPN profile to Windows Information Protection (WIP), and more |
+| [VPN profile options](vpn-profile-options.md)  | Combine settings into single VPN profile using XML |
+
+## Learn more
+
+- [Create VPN profiles to connect to VPN servers in Intune](/mem/intune/configuration/vpn-settings-configure)

windows/security/operating-system-security/network-security/vpn/vpn-name-resolution.md

@@ -0,0 +1,71 @@
+---
+title: VPN name resolution
+description: Learn how name resolution works when using a VPN connection.
+ms.date: 05/24/2023
+ms.topic: conceptual
+---
+
+# VPN name resolution
+
+When the VPN client establishes a connection, it receives an IP address and, optionally, the IP address of one or more DNS servers.
+
+The name resolution setting in the VPN profile determines how name resolution works on the system when the VPN connection is established:
+
+1. The network stack looks at the Name Resolution Policy table (NRPT) for any matches, and tries a resolution if a match is found
+1. If no match is found, the DNS suffix on the most preferred interface based on the interface metric is appended to the name (if a short name is used). A DNS query is sent to the preferred interface
+1. If the query times out, the DNS suffix search list is used in order and DNS queries are sent on all interfaces
+
+## Name Resolution Policy table (NRPT)
+
+The NRPT is a table of namespaces that determines the DNS client's behavior when issuing name resolution queries and processing responses. It's the first place that the stack will look after the DNSCache.
+
+There are three types of name matches that can  set up for NRPT:
+
+- Fully qualified domain name (FQDN) that can be used for direct matching to a name
+- Suffix match results in either a comparison of suffixes (for FQDN resolution) or the appending of the suffix (if using short name)
+- Any resolution should attempt to first resolve with the proxy server/DNS server with this entry
+
+NRPT is set using the `VPNv2/<ProfileName>/DomainNameInformationList` node of the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp). You can use the same node to configure a Web proxy server or DNS.
+
+To learn more about NRPT, see [Introduction to the NRPT](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee649207(v=ws.10)).
+
+## DNS suffix
+
+The DNS suffix setting is used to configure the primary DNS suffix for the VPN interface and the suffix search list after the VPN connection is established.
+
+Primary DNS suffix is set using the `VPNv2/<ProfileName>/DnsSuffix` node.
+
+[Learn more about primaryDNS suffix](/previous-versions/windows/it-pro/windows-2000-server/cc959611(v=technet.10))
+
+## Persistent name resolution rules
+
+You can configure *persistent* name resolution rules. Name resolution for the specified items is done over the VPN.
+
+Persistent name resolution is set using the `VPNv2/<ProfileName>/DomainNameInformationList/<dniRowId>/Persistent` node.
+
+## Configure name resolution
+
+See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
+
+The following image shows name resolution options in a VPN Profile configuration policy using Microsoft Intune.
+
+:::image type="content" source="images/vpn-name-intune.png" alt-text="Creation of VPN profile in Intune: DNS options." lightbox="images/vpn-name-intune.png":::
+
+The fields in **Add or edit DNS rule** in the Intune profile correspond to the XML settings shown in the following table.
+
+| Field | XML |
+| --- | --- |
+| **Name** | **VPNv2/*ProfileName*/DomainNameInformationList/*dniRowId*/DomainName**  |
+| **Servers (comma separated)** | **VPNv2/*ProfileName*/DomainNameInformationList/*dniRowId*/DnsServers**  |
+| **Proxy server** |  **VPNv2/*ProfileName*/DomainNameInformationList/*dniRowId*/WebServers**  |
+
+## Related articles
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN security features](vpn-security-features.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/vpn/vpn-office-365-optimization.md

@@ -0,0 +1,650 @@
+---
+title: Optimize Microsoft 365 traffic for remote workers with the Windows VPN client
+description: Learn how to optimize Microsoft 365 traffic for remote workers with the Windows VPN client
+ms.topic: article
+ms.date: 05/24/2023
+---
+# Optimize Microsoft 365 traffic for remote workers with the Windows VPN client
+
+This article describes how to configure the recommendations in the article [VPN split tunneling for Microsoft 365](/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel) for the Windows VPN client. This guidance enables VPN administrators to optimize Microsoft 365 usage while ensuring that all other traffic goes over the VPN connection and through existing security gateways or tooling.
+
+The recommendations can be implemented for the built-in Windows VPN client using a *Force Tunneling with Exclusions* approach, defining IP-based exclusions even when using *force tunneling*. Certain traffic can be *split* to use the physical interface, while still forcing all other traffic via the VPN interface. Traffic addressed to defined destinations (like those listed in the Microsoft 365 optimized categories) follows a much more direct and efficient path, without the need to traverse or *hairpin* via the VPN tunnel and back out of the organization's network. For cloud-services like Microsoft 365, this makes a significant difference in performance and usability for remote users.
+
+> [!NOTE]
+> The term *force tunneling with exclusions* is sometimes confusingly called *split tunnels* by other vendors and in some online documentation. For Windows VPN, the term *split tunneling* is defined differently, as described in the article [VPN routing decisions](./vpn-routing.md#split-tunnel-configuration).
+
+## Solution Overview
+
+The solution is based upon the use of a VPN Configuration Service Provider Reference profile ([VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp)) and the embedded [ProfileXML](/windows/client-management/mdm/vpnv2-profile-xsd). These are used to configure the VPN profile on the device. Various provisioning approaches can be used to create and deploy the VPN profile as discussed in the article [Step 6. Configure Windows 10 client Always On VPN connections](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#create-the-profilexml-configuration-files).
+
+Typically, these VPN profiles are distributed using a Mobile Device Management solution like Intune, as described in [VPN profile options](./vpn-profile-options.md#apply-profilexml-using-intune) and [Configure the VPN client by using Intune](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#configure-the-vpn-client-by-using-intune).
+
+To enable the use of force tunneling in Windows 10 or Windows 11 VPN, the `<RoutingPolicyType>` setting is typically configured with a value of _ForceTunnel_ in your existing Profile XML (or script) by way of the following entry, under the `<NativeProfile></NativeProfile>` section:
+
+```xml
+<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
+```
+
+In order to define specific force tunnel exclusions, you then need to add the following lines to your existing Profile XML (or script) for each required exclusion, and place them outside of the `<NativeProfile></NativeProfile>` section as follows:
+
+```xml
+<Route>
+ <Address>[IP addresses or subnet]</Address>
+ <PrefixSize>[IP Prefix]</PrefixSize>
+ <ExclusionRoute>true</ExclusionRoute>
+</Route>
+```
+
+Entries defined by the `[IP Addresses or Subnet]` and `[IP Prefix]` references will consequently be added to the routing table as _more specific route entries_ that will use the Internet-connected interface as the default gateway, as opposed to using the VPN interface. You must define a unique and separate `<Route></Route>` section for each required exclusion.
+
+An example of a correctly formatted Profile XML configuration for force tunnel with exclusions is the following:
+
+```xml
+<VPNProfile>
+ <NativeProfile>
+  <RoutingPolicyType>ForceTunnel</RoutingPolicyType>
+ </NativeProfile>
+ <Route>
+  <Address>203.0.113.0</Address>
+  <PrefixSize>24</PrefixSize>
+  <ExclusionRoute>true</ExclusionRoute>
+ </Route>
+ <Route>
+  <Address>198.51.100.0</Address>
+  <PrefixSize>22</PrefixSize>
+  <ExclusionRoute>true</ExclusionRoute>
+ </Route>
+</VPNProfile>
+```
+
+> [!NOTE]
+> The IP addresses and prefix size values in this example are used purely as examples only and should not be used.
+
+## Solution Deployment
+
+For Microsoft 365, it's therefore necessary to add exclusions for all IP addresses documented within the optimize categories described in [Office 365 URLs and IP address ranges](/microsoft-365/enterprise/urls-and-ip-address-ranges) to ensure that they're excluded from VPN force tunneling.
+
+This can be achieved manually by adding the IP addresses defined within the *optimize* category entries to an existing Profile XML (or script) file, or alternatively the following script can be used which dynamically adds the required entries to an existing PowerShell script, or XML file, based upon directly querying the REST-based web service to ensure the correct IP address ranges are always used.
+
+An example of a PowerShell script that can be used to update a force tunnel VPN connection with Microsoft 365 exclusions is provided below.
+
+```powershell
+# Copyright (c) Microsoft Corporation.  All rights reserved.
+#  
+# THIS SAMPLE CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
+# WHETHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
+# IF THIS CODE AND INFORMATION IS MODIFIED, THE ENTIRE RISK OF USE OR RESULTS IN
+# CONNECTION WITH THE USE OF THIS CODE AND INFORMATION REMAINS WITH THE USER.
+
+<#
+.SYNOPSIS
+    Applies or updates recommended Microsoft 365 optimize IP address exclusions to an existing force tunnel Windows 10 and Windows 11 VPN profile
+.DESCRIPTION
+    Connects to the Microsoft 365 worldwide commercial service instance endpoints to obtain the latest published IP address ranges
+    Compares the optimized IP addresses with those contained in the supplied VPN Profile (PowerShell or XML file)
+    Adds or updates IP addresses as necessary and saves the resultant file with "-NEW" appended to the file name
+.PARAMETERS
+    Filename and path for a supplied Windows 10 or Windows 11 VPN profile file in either PowerShell or XML format
+.NOTES
+    Requires at least Windows 10 Version 1803 with KB4493437, 1809 with KB4490481, or later
+.VERSION
+    1.0
+#>
+
+param (
+    [string]$VPNprofilefile
+)
+
+$usage=@"
+
+This script uses the following parameters:
+
+VPNprofilefile - The full path and name of the VPN profile PowerShell script or XML file
+
+EXAMPLES
+
+To check a VPN profile PowerShell script file:
+
+Update-VPN-Profile-Office365-Exclusion-Routes.ps1 -VPNprofilefile [FULLPATH AND NAME OF POWERSHELL SCRIPT FILE]
+
+To check a VPN profile XML file:
+
+Update-VPN-Profile-Office365-Exclusion-Routes.ps1 -VPNprofilefile [FULLPATH AND NAME OF XML FILE]
+
+"@
+  
+# Check if filename has been provided #
+if ($VPNprofilefile -eq "")
+{
+   Write-Host "`nWARNING: You must specify either a PowerShell script or XML filename!" -ForegroundColor Red
+
+    $usage
+    exit
+}
+
+$FileExtension = [System.IO.Path]::GetExtension($VPNprofilefile)
+
+# Check if XML file exists and is a valid XML file #
+if ( $VPNprofilefile -ne "" -and $FileExtension -eq ".xml")
+{
+    if ( Test-Path $VPNprofilefile )
+    {
+        $xml = New-Object System.Xml.XmlDocument
+        try
+        {
+            $xml.Load((Get-ChildItem -Path $VPNprofilefile).FullName)
+
+        }
+        catch [System.Xml.XmlException]
+        {
+            Write-Verbose "$VPNprofilefile : $($_.toString())"
+            Write-Host "`nWARNING: The VPN profile XML file is not a valid xml file or incorrectly formatted!" -ForegroundColor Red
+            $usage
+            exit
+        }
+    }else
+    {
+        Write-Host "`nWARNING: VPN profile XML file does not exist or cannot be found!" -ForegroundColor Red
+        $usage
+        exit
+    }
+}
+
+# Check if VPN profile PowerShell script file exists and contains a VPNPROFILE XML section #
+if ( $VPNprofilefile -ne "" -and $FileExtension -eq ".ps1")
+{
+    if ( (Test-Path $VPNprofilefile) )
+    {
+        if (-Not $(Select-String -Path $VPNprofilefile -Pattern "<VPNPROFILE>") )
+        {
+            Write-Host "`nWARNING: PowerShell script file does not contain a valid VPN profile XML section or is incorrectly formatted!" -ForegroundColor Red
+            $usage
+            exit
+        }
+    }else
+    {
+        Write-Host "`nWARNING: PowerShell script file does not exist or cannot be found!"-ForegroundColor Red
+        $usage
+        exit
+    }
+}
+
+# Define Microsoft 365 endpoints and service URLs #
+$ws = "https://endpoints.office.com"
+$baseServiceUrl = "https://endpoints.office.com"
+
+# Path where client ID and latest version number will be stored #
+$datapath = $Env:TEMP + "\endpoints_clientid_latestversion.txt"
+
+# Fetch client ID and version if data file exists; otherwise create new file #
+if (Test-Path $datapath)
+{
+    $content = Get-Content $datapath
+    $clientRequestId = $content[0]
+    $lastVersion = $content[1]
+
+}else
+{
+    $clientRequestId = [GUID]::NewGuid().Guid
+    $lastVersion = "0000000000"
+    @($clientRequestId, $lastVersion) | Out-File $datapath
+}
+
+# Call version method to check the latest version, and pull new data if version number is different #
+$version = Invoke-RestMethod -Uri ($ws + "/version?clientRequestId=" + $clientRequestId)
+
+if ($version[0].latest -gt $lastVersion)
+{
+
+    Write-Host
+    Write-Host "A new version of Microsoft 365 worldwide commercial service instance endpoints has been detected!" -ForegroundColor Cyan
+
+    # Write the new version number to the data file #
+    @($clientRequestId, $version[0].latest) | Out-File $datapath
+}
+
+# Invoke endpoints method to get the new data #
+$uri = "$baseServiceUrl" + "/endpoints/worldwide?clientRequestId=$clientRequestId"
+
+# Invoke endpoints method to get the data for the VPN profile comparison #
+$endpointSets = Invoke-RestMethod -Uri ($uri)
+$Optimize = $endpointSets | Where-Object { $_.category -eq "Optimize" }
+$optimizeIpsv4 = $Optimize.ips | Where-Object { ($_).contains(".") } | Sort-Object -Unique
+
+# Temporarily include additional IP address until Teams client update is released
+$optimizeIpsv4 += "13.107.60.1/32"
+
+# Process PowerShell script file start #
+if ($VPNprofilefile -ne "" -and $FileExtension -eq ".ps1")
+{
+    Write-host "`nStarting PowerShell script exclusion route check...`n" -ForegroundColor Cyan
+
+    # Clear Variables to allow re-run testing #
+
+    $ARRVPN=$null              # Array to hold VPN addresses from VPN profile PowerShell file #
+    $In_Opt_Only=$null         # Variable to hold IP addresses that only appear in the optimize list #
+    $In_VPN_Only=$null         # Variable to hold IP addresses that only appear in the VPN profile PowerShell file #
+
+    # Extract the Profile XML from the ps1 file #
+
+    $regex = '(?sm).*^*.<VPNProfile>\r?\n(.*?)\r?\n</VPNProfile>.*'
+
+    # Create xml format variable to compare with the optimize list #
+
+    $xmlbody=(Get-Content -Raw $VPNprofilefile) -replace $regex, '$1'
+    [xml]$VPNprofilexml="<VPNProfile>"+$xmlbody+"</VPNProfile>"
+
+        # Loop through each address found in VPNPROFILE XML section #
+        foreach ($Route in $VPNprofilexml.VPNProfile.Route)
+        {
+        $VPNIP=$Route.Address+"/"+$Route.PrefixSize
+        [array]$ARRVPN=$ARRVPN+$VPNIP
+        }
+
+    # In optimize address list only #
+    $In_Opt_Only= $optimizeIpsv4 | Where {$ARRVPN -NotContains $_}
+
+    # In VPN list only #
+    $In_VPN_only =$ARRVPN | Where {$optimizeIpsv4 -NotContains $_}
+    [array]$Inpfile = get-content $VPNprofilefile
+
+    if ($In_Opt_Only.Count -gt 0 )
+    {
+        Write-Host "Exclusion route IP addresses are unknown, missing, or need to be updated in the VPN profile`n" -ForegroundColor Red
+
+         [int32]$insline=0
+
+            for ($i=0; $i -lt $Inpfile.count; $i++)
+            {
+                if ($Inpfile[$i] -match "</NativeProfile>")
+                {
+                $insline += $i # Record the position of the line after the NativeProfile section ends #
+                }
+            }
+            $OFS = "`r`n"
+                foreach ($NewIP in $In_Opt_Only)
+                {
+                    # Add the missing IP address(es) #
+                    $IPInfo=$NewIP.Split("/")
+                    $InpFile[$insline] += $OFS+"    <Route>"
+                    $InpFile[$insline] += $OFS+"      <Address>"+$IPInfo[0].Trim()+"</Address>"
+                    $InpFile[$insline] += $OFS+"      <PrefixSize>"+$IPInfo[1].Trim()+"</PrefixSize>"
+                    $InpFile[$insline] += $OFS+"      <ExclusionRoute>true</ExclusionRoute>"
+                    $InpFile[$insline] += $OFS+"    </Route>"
+                }
+             # Update fileName and write new PowerShell file #
+             $NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.ps1"
+             $OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
+             $InpFile | Set-Content $OutFile
+             Write-Host "Exclusion routes have been added to VPN profile and output to a separate PowerShell script file; the original file has not been modified`n" -ForegroundColor Green
+    }else
+    {
+        Write-Host "Exclusion route IP addresses are correct and up to date in the VPN profile`n" -ForegroundColor Green
+        $OutFile=$VPNprofilefile
+    }
+
+if ( $In_VPN_Only.Count -gt 0 )
+{
+    Write-Host "Unknown exclusion route IP addresses have been found in the VPN profile`n" -ForegroundColor Yellow
+
+        foreach ($OldIP in $In_VPN_Only)
+        {
+            [array]$Inpfile = get-content $Outfile
+            $IPInfo=$OldIP.Split("/")
+            Write-Host "Unknown exclusion route IP address"$IPInfo[0]"has been found in the VPN profile - Do you wish to remove it? (Y/N)`n" -ForegroundColor Yellow
+            $matchstr="<Address>"+$IPInfo[0].Trim()+"</Address>"
+            $DelAns=Read-host
+                if ($DelAns.ToUpper() -eq "Y")
+                {
+                    [int32]$insline=0
+                        for ($i=0; $i -lt $Inpfile.count; $i++)
+                        {
+                            if ($Inpfile[$i] -match $matchstr)
+                            {
+                                $insline += $i # Record the position of the line for the string match #
+                            }
+                        }
+                        # Remove entries from XML #
+                        $InpFile[$insline-1]="REMOVETHISLINE"
+                        $InpFile[$insline]="REMOVETHISLINE"
+                        $InpFile[$insline+1]="REMOVETHISLINE"
+                        $InpFile[$insline+2]="REMOVETHISLINE"
+                        $InpFile[$insline+3]="REMOVETHISLINE"
+                        $InpFile=$InpFile | Where-Object {$_ -ne "REMOVETHISLINE"}
+
+                        # Update filename and write new PowerShell file #
+                        $NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.xml"
+                        $OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
+                        $Inpfile | Set-content $OutFile
+                        Write-Host "`nAddress"$IPInfo[0]"exclusion route has been removed from the VPN profile and output to a separate PowerShell script file; the original file has not been modified`n" -ForegroundColor Green
+
+                }else
+                {
+                    Write-Host "`nExclusion route IP address has *NOT* been removed from the VPN profile`n" -ForegroundColor Green
+                }
+        }
+ }
+}
+
+# Process XML file start #
+if ($VPNprofilefile -ne "" -and $FileExtension -eq ".xml")
+{
+    Write-host "`nStarting XML file exclusion route check...`n" -ForegroundColor Cyan
+
+    # Clear variables to allow re-run testing #
+    $ARRVPN=$null              # Array to hold VPN addresses from the XML file #
+    $In_Opt_Only=$null         # Variable to hold IP Addresses that only appear in optimize list #
+    $In_VPN_Only=$null         # Variable to hold IP Addresses that only appear in the VPN profile XML file #  
+
+    # Extract the Profile XML from the XML file #
+    $regex = '(?sm).*^*.<VPNProfile>\r?\n(.*?)\r?\n</VPNProfile>.*'
+
+    # Create xml format variable to compare with optimize list #
+    $xmlbody=(Get-Content -Raw $VPNprofilefile) -replace $regex, '$1'
+    [xml]$VPNRulesxml="$xmlbody"
+
+        # Loop through each address found in VPNPROFILE file #
+        foreach ($Route in $VPNRulesxml.VPNProfile.Route)
+        {
+            $VPNIP=$Route.Address+"/"+$Route.PrefixSize
+            [array]$ARRVPN=$ARRVPN+$VPNIP
+        }
+
+    # In optimize address list only #
+    $In_Opt_Only= $optimizeIpsv4 | Where {$ARRVPN -NotContains $_}
+
+    # In VPN list only #
+    $In_VPN_only =$ARRVPN | Where {$optimizeIpsv4 -NotContains $_}
+    [System.Collections.ArrayList]$Inpfile = get-content $VPNprofilefile
+
+        if ($In_Opt_Only.Count -gt 0 )
+        {
+            Write-Host "Exclusion route IP addresses are unknown, missing, or need to be updated in the VPN profile`n" -ForegroundColor Red
+
+                foreach ($NewIP in $In_Opt_Only)
+                {
+                    # Add the missing IP address(es) #
+                    $IPInfo=$NewIP.Split("/")
+                    $routes += "<Route>`n"+"`t<Address>"+$IPInfo[0].Trim()+"</Address>`n"+"`t<PrefixSize>"+$IPInfo[1].Trim()+"</PrefixSize>`n"+"`t<ExclusionRoute>true</ExclusionRoute>`n"+"</Route>`n"
+                }
+            $inspoint = $Inpfile.IndexOf("</VPNProfile>")
+            $Inpfile.Insert($inspoint,$routes)
+
+            # Update filename and write new XML file #
+            $NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.xml"
+            $OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
+            $InpFile | Set-Content $OutFile
+            Write-Host "Exclusion routes have been added to VPN profile and output to a separate XML file; the original file has not been modified`n`n" -ForegroundColor Green
+
+        }else
+        {
+            Write-Host "Exclusion route IP addresses are correct and up to date in the VPN profile`n" -ForegroundColor Green
+            $OutFile=$VPNprofilefile
+        }
+
+        if ( $In_VPN_Only.Count -gt 0 )
+        {
+            Write-Host "Unknown exclusion route IP addresses found in the VPN profile`n" -ForegroundColor Yellow
+
+            foreach ($OldIP in $In_VPN_Only)
+            {
+                [array]$Inpfile = get-content $OutFile
+                $IPInfo=$OldIP.Split("/")
+                Write-Host "Unknown exclusion route IP address"$IPInfo[0]"has been found in the VPN profile - Do you wish to remove it? (Y/N)`n" -ForegroundColor Yellow
+                $matchstr="<Route>"+"<Address>"+$IPInfo[0].Trim()+"</Address>"+"<PrefixSize>"+$IPInfo[1].Trim()+"</PrefixSize>"+"<ExclusionRoute>true</ExclusionRoute>"+"</Route>"
+                $DelAns=Read-host
+                    if ($DelAns.ToUpper() -eq "Y")
+                    {
+                        # Remove unknown IP address(es) #
+                        $inspoint = $Inpfile[0].IndexOf($matchstr)
+                        $Inpfile[0] = $Inpfile[0].Replace($matchstr,"")
+
+                        # Update filename and write new XML file #
+                        $NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.xml"
+                        $OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
+                        $Inpfile | Set-content $OutFile
+                        Write-Host "`nAddress"$IPInfo[0]"exclusion route has been removed from the VPN profile and output to a separate XML file; the original file has not been modified`n" -ForegroundColor Green
+
+                    }else
+                    {
+                        Write-Host "`nExclusion route IP address has *NOT* been removed from the VPN profile`n" -ForegroundColor Green
+                    }
+            }
+        }
+}
+```
+
+## Other Considerations
+
+You should also be able to adapt this approach to include necessary exclusions for other cloud-services that can be defined by known/static IP addresses; exclusions required for [Cisco WebEx](https://help.webex.com/WBX000028782/Network-Requirements-for-Webex-Teams-Services) or [Zoom](https://support.zoom.us/hc/en-us/articles/201362683) are good examples.
+
+## Examples
+
+An example of a PowerShell script that can be used to create a force tunnel VPN connection with Microsoft 365 exclusions is provided below, or refer to the guidance in [Create the ProfileXML configuration files](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#create-the-profilexml-configuration-files) to create the initial PowerShell script:
+
+```powershell
+# Copyright (c) Microsoft Corporation.  All rights reserved.
+#
+# THIS SAMPLE CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
+# WHETHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
+# IF THIS CODE AND INFORMATION IS MODIFIED, THE ENTIRE RISK OF USE OR RESULTS IN
+# CONNECTION WITH THE USE OF THIS CODE AND INFORMATION REMAINS WITH THE USER.
+
+<#
+.SYNOPSIS
+    Configures an AlwaysOn IKEv2 VPN Connection using a basic script
+.DESCRIPTION
+    Configures an AlwaysOn IKEv2 VPN Connection with proxy PAC information and force tunneling
+.PARAMETERS
+    Parameters are defined in a ProfileXML object within the script itself
+.NOTES
+    Requires at least Windows 10 Version 1803 with KB4493437, 1809 with KB4490481, or later
+.VERSION
+    1.0
+#>
+
+<#-- Define Key VPN Profile Parameters --#>
+$ProfileName = 'Contoso VPN with Microsoft 365 Exclusions'
+$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
+
+<#-- Define VPN ProfileXML --#>
+$ProfileXML = '<VPNProfile>
+      <RememberCredentials>true</RememberCredentials>
+    <DnsSuffix>corp.contoso.com</DnsSuffix>
+    <AlwaysOn>true</AlwaysOn>
+    <TrustedNetworkDetection>corp.contoso.com</TrustedNetworkDetection>
+<NativeProfile>
+        <Servers>edge1.contoso.com</Servers>
+        <RoutingPolicyType>ForceTunnel</RoutingPolicyType>
+        <NativeProtocolType>IKEv2</NativeProtocolType>
+        <Authentication>
+            <MachineMethod>Certificate</MachineMethod>
+        </Authentication>
+    </NativeProfile>
+    <Route>
+      <Address>13.107.6.152</Address>
+      <PrefixSize>31</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>13.107.18.10</Address>
+      <PrefixSize>31</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>13.107.128.0</Address>
+      <PrefixSize>22</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>23.103.160.0</Address>
+      <PrefixSize>20</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>40.96.0.0</Address>
+      <PrefixSize>13</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>40.104.0.0</Address>
+      <PrefixSize>15</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>52.96.0.0</Address>
+      <PrefixSize>14</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>131.253.33.215</Address>
+      <PrefixSize>32</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>132.245.0.0</Address>
+      <PrefixSize>16</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>150.171.32.0</Address>
+      <PrefixSize>22</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>191.234.140.0</Address>
+      <PrefixSize>22</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>204.79.197.215</Address>
+      <PrefixSize>32</PrefixSize>
+    <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>13.107.136.0</Address>
+      <PrefixSize>22</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>40.108.128.0</Address>
+      <PrefixSize>17</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>52.104.0.0</Address>
+      <PrefixSize>14</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>104.146.128.0</Address>
+      <PrefixSize>17</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>  
+    <Route>
+      <Address>150.171.40.0</Address>
+      <PrefixSize>22</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>  
+    <Route>
+      <Address>13.107.60.1</Address>
+      <PrefixSize>32</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>13.107.64.0</Address>
+     <PrefixSize>18</PrefixSize>
+    <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>52.112.0.0</Address>
+      <PrefixSize>14</PrefixSize>
+      <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Route>
+      <Address>52.120.0.0</Address>
+      <PrefixSize>14</PrefixSize>
+    <ExclusionRoute>true</ExclusionRoute>
+    </Route>
+    <Proxy>  
+            <AutoConfigUrl>http://webproxy.corp.contoso.com/proxy.pac</AutoConfigUrl>  
+      </Proxy>  
+</VPNProfile>'
+
+<#-- Convert ProfileXML to Escaped Format --#>
+$ProfileXML = $ProfileXML -replace '<', '&lt;'
+$ProfileXML = $ProfileXML -replace '>', '&gt;'
+$ProfileXML = $ProfileXML -replace '"', '&quot;'
+
+<#-- Define WMI-to-CSP Bridge Properties --#>
+$nodeCSPURI = './Vendor/MSFT/VPNv2'
+$namespaceName = "root\cimv2\mdm\dmmap"
+$className = "MDM_VPNv2_01"
+
+<#-- Define WMI Session --#>
+$session = New-CimSession
+
+<#-- Detect and Delete Previous VPN Profile --#>
+try
+{
+    $deleteInstances = $session.EnumerateInstances($namespaceName, $className, $options)
+    foreach ($deleteInstance in $deleteInstances)
+    {
+        $InstanceId = $deleteInstance.InstanceID
+        if ("$InstanceId" -eq "$ProfileNameEscaped")
+        {
+            $session.DeleteInstance($namespaceName, $deleteInstance, $options)
+            $Message = "Removed $ProfileName profile $InstanceId"
+            Write-Host "$Message"
+        } else {
+            $Message = "Ignoring existing VPN profile $InstanceId"
+            Write-Host "$Message"
+        }
+    }
+}
+catch [Exception]
+{
+    $Message = "Unable to remove existing outdated instance(s) of $ProfileName profile: $_"
+    Write-Host "$Message"
+    exit
+}
+
+<#-- Create VPN Profile --#>
+try
+{
+    $newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
+    $property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI", 'String', 'Key')
+    $newInstance.CimInstanceProperties.Add($property)
+    $property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID", "$ProfileNameEscaped", 'String', 'Key')
+    $newInstance.CimInstanceProperties.Add($property)
+    $property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML", 'String', 'Property')
+    $newInstance.CimInstanceProperties.Add($property)
+
+    $session.CreateInstance($namespaceName, $newInstance, $options)
+    $Message = "Created $ProfileName profile."
+    Write-Host "$Message"
+    Write-Host "$ProfileName profile summary:"  
+    $session.EnumerateInstances($namespaceName, $className, $options)
+}
+catch [Exception]
+{
+    $Message = "Unable to create $ProfileName profile: $_"
+    Write-Host "$Message"
+    exit
+}
+
+$Message = "Script Complete"
+Write-Host "$Message"
+
+```
+
+An example of an [Intune-ready XML file](./vpn-profile-options.md#apply-profilexml-using-intune) that can be used to create a force tunnel VPN connection with Microsoft 365 exclusions is provided below, or refer to the guidance in [Create the ProfileXML configuration files](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#create-the-profilexml-configuration-files) to create the initial XML file.
+
+>[!NOTE]
+>This XML is formatted for use with Intune and cannot contain any carriage returns or whitespace.
+
+```xml
+<VPNProfile><RememberCredentials>true</RememberCredentials><DnsSuffix>corp.contoso.com</DnsSuffix><AlwaysOn>true</AlwaysOn><TrustedNetworkDetection>corp.contoso.com</TrustedNetworkDetection><NativeProfile><Servers>edge1.contoso.com</Servers><RoutingPolicyType>ForceTunnel</RoutingPolicyType><NativeProtocolType>IKEv2</NativeProtocolType><Authentication><MachineMethod>Certificate</MachineMethod></Authentication></NativeProfile><Route><Address>13.107.6.152</Address><PrefixSize>31</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.18.10</Address><PrefixSize>31</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.128.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>23.103.160.0</Address><PrefixSize>20</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>40.96.0.0</Address><PrefixSize>13</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>40.104.0.0</Address><PrefixSize>15</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.96.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>131.253.33.215</Address><PrefixSize>32</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>132.245.0.0</Address><PrefixSize>16</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>150.171.32.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>191.234.140.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>204.79.197.215</Address><PrefixSize>32</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.136.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>40.108.128.0</Address><PrefixSize>17</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.104.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>104.146.128.0</Address><PrefixSize>17</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>150.171.40.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.60.1</Address><PrefixSize>32</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.64.0</Address><PrefixSize>18</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.112.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.120.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Proxy><AutoConfigUrl>http://webproxy.corp.contoso.com/proxy.pac</AutoConfigUrl></Proxy></VPNProfile>
+```

windows/security/operating-system-security/network-security/vpn/vpn-profile-options.md

@@ -0,0 +1,329 @@
+---
+title: VPN profile options 
+description: Windows adds Virtual Private Network (VPN) profile options to help manage how users connect. VPNs give users secure remote access to the company network.
+ms.date: 05/17/2018
+ms.topic: conceptual
+---
+
+# VPN profile options
+
+Most of the VPN settings in Windows 10 and Windows 11 can be configured in VPN profiles using Microsoft Intune or Microsoft Configuration Manager. All VPN settings in Windows 10 and Windows 11 can be configured using the **ProfileXML** node in the [VPNv2 configuration service provider (CSP)](/windows/client-management/mdm/vpnv2-csp). 
+
+>[!NOTE]
+>If you're not familiar with CSPs, read [Introduction to configuration service providers (CSPs)](/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers) first.
+
+The following table lists the VPN settings and whether the setting can be configured in Intune and Configuration Manager, or can only be configured using **ProfileXML**.
+
+| Profile setting | Can be configured in Intune and Configuration Manager | 
+| --- | --- | 
+| Connection type | Yes | 
+| Routing: split-tunnel routes | Yes, except exclusion routes |
+| Routing: forced-tunnel | Yes |
+| Authentication (EAP) | Yes, if connection type is built in |
+| Conditional access | Yes |
+| Name resolution: NRPT | Yes |
+| Name resolution: DNS suffix | No |
+| Name resolution: persistent | No |
+| Auto-trigger: app trigger | Yes |
+| Auto-trigger: name trigger | Yes |
+| Auto-trigger: Always On | Yes |
+| Auto-trigger: trusted network detection | No |
+| LockDown | No |
+| Windows Information Protection (WIP) | Yes |
+| Traffic filters | Yes |
+| Proxy settings | Yes, by PAC/WPAD file or server and port |
+
+> [!NOTE] 
+> VPN proxy settings are only used on Force Tunnel Connections. On Split Tunnel Connections, the general proxy settings are used.
+
+The ProfileXML node was added to the VPNv2 CSP to allow users to deploy VPN profile as a single blob. This node is useful for deploying profiles with features that aren't yet supported by MDMs. You can get more examples in the [ProfileXML XSD](/windows/client-management/mdm/vpnv2-profile-xsd) article.
+
+
+## Sample Native VPN profile
+
+The following sample is a sample Native VPN profile. This blob would fall under the ProfileXML node. 
+
+```xml
+<VPNProfile>  
+  <ProfileName>TestVpnProfile</ProfileName>  
+  <NativeProfile>  
+    <Servers>testServer.VPN.com</Servers>  
+    <NativeProtocolType>IKEv2</NativeProtocolType> 
+    
+    <!--Sample EAP profile (PEAP)--> 
+    <Authentication>  
+      <UserMethod>Eap</UserMethod> 
+      <Eap>  
+       <Configuration>
+          <EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
+            <EapMethod>
+              <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">25</Type>
+              <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
+              <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
+              <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
+            </EapMethod>
+            <Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
+              <Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
+                <Type>25</Type>
+                <EapType xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV1">
+                  <ServerValidation>
+                    <DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
+                    <ServerNames></ServerNames>
+                    <TrustedRootCA>d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2 </TrustedRootCA>
+                    <TrustedRootCA>d1 76 97 cc 20 6e d2 6e 1a 51 f5 bb 96 e9 35 6d 6d 61 0b 74 </TrustedRootCA>
+                  </ServerValidation>
+                  <FastReconnect>true</FastReconnect>
+                  <InnerEapOptional>false</InnerEapOptional>
+                  <Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
+                    <Type>13</Type>
+                    <EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
+                      <CredentialsSource>
+                        <CertificateStore>
+                          <SimpleCertSelection>true</SimpleCertSelection>
+                        </CertificateStore>
+                      </CredentialsSource>
+                      <ServerValidation>
+                        <DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
+                        <ServerNames></ServerNames>
+                        <TrustedRootCA>d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2 </TrustedRootCA>
+                        <TrustedRootCA>d1 76 97 cc 20 6e d2 6e 1a 51 f5 bb 96 e9 35 6d 6d 61 0b 74 </TrustedRootCA>
+                      </ServerValidation>
+                      <DifferentUsername>false</DifferentUsername>
+                      <PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation>
+                      <AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
+                      <TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">
+                        <FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3">
+                          <EKUMapping>
+                            <EKUMap>
+                              <EKUName>AAD Conditional Access</EKUName>
+                              <EKUOID>1.3.6.1.4.1.311.87</EKUOID>
+                            </EKUMap>
+                          </EKUMapping>
+                          <ClientAuthEKUList Enabled="true">
+                            <EKUMapInList>
+                              <EKUName>AAD Conditional Access</EKUName>
+                            </EKUMapInList>
+                          </ClientAuthEKUList>
+                        </FilteringInfo>
+                      </TLSExtensions>
+                    </EapType>
+                  </Eap>
+                  <EnableQuarantineChecks>false</EnableQuarantineChecks>
+                  <RequireCryptoBinding>true</RequireCryptoBinding>
+                  <PeapExtensions>
+                    <PerformServerValidation xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">true</PerformServerValidation>
+                    <AcceptServerName xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">false</AcceptServerName>
+                  </PeapExtensions>
+                </EapType>
+              </Eap>
+            </Config>
+          </EapHostConfig>
+        </Configuration>
+      </Eap>  
+    </Authentication>  
+    
+    <!--Sample routing policy: in this case, this is a split tunnel configuration with two routes configured-->
+    <RoutingPolicyType>SplitTunnel</RoutingPolicyType>  
+    <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>  
+  </NativeProfile>  
+    <Route>  
+    <Address>192.168.0.0</Address>  
+    <PrefixSize>24</PrefixSize>  
+  </Route>  
+  <Route>  
+    <Address>10.10.0.0</Address>  
+    <PrefixSize>16</PrefixSize>  
+  </Route>  
+  
+  <!--VPN will be triggered for the two apps specified here-->
+  <AppTrigger>  
+    <App>  
+      <Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>  
+    </App>  
+  </AppTrigger>  
+  <AppTrigger>  
+    <App>  
+      <Id>C:\windows\system32\ping.exe</Id>  
+    </App>  
+  </AppTrigger>  
+  
+  <!--Example of per-app VPN. This configures traffic filtering rules for two apps. Internet Explorer is configured for force tunnel, meaning that all traffic allowed through this app must go over VPN. Microsoft Edge is configured as split tunnel, so whether data goes over VPN or the physical interface is dictated by the routing configuration.-->
+  <TrafficFilter>  
+    <App>  
+      <Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>  
+    </App>  
+    <Protocol>6</Protocol>  
+    <LocalPortRanges>10,20-50,100-200</LocalPortRanges>  
+    <RemotePortRanges>20-50,100-200,300</RemotePortRanges>  
+    <RemoteAddressRanges>30.30.0.0/16,10.10.10.10-20.20.20.20</RemoteAddressRanges>  
+    <RoutingPolicyType>ForceTunnel</RoutingPolicyType>  
+  </TrafficFilter>  
+  <TrafficFilter>  
+    <App>  
+      <Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>  
+    </App>  
+    <LocalAddressRanges>3.3.3.3/32,1.1.1.1-2.2.2.2</LocalAddressRanges>  
+  </TrafficFilter>  
+  
+  <!--Name resolution configuration. The AutoTrigger node configures name-based triggering. In this profile, the domain "hrsite.corporate.contoso.com" triggers VPN.-->
+  <DomainNameInformation>  
+    <DomainName>hrsite.corporate.contoso.com</DomainName>  
+    <DnsServers>1.2.3.4,5.6.7.8</DnsServers>  
+    <WebProxyServers>5.5.5.5</WebProxyServers>  
+    <AutoTrigger>true</AutoTrigger>  
+  </DomainNameInformation>  
+  <DomainNameInformation>  
+    <DomainName>.corp.contoso.com</DomainName>  
+    <DnsServers>10.10.10.10,20.20.20.20</DnsServers>  
+    <WebProxyServers>100.100.100.100</WebProxyServers>  
+  </DomainNameInformation>  
+  
+  <!--EDPMode is turned on for the enterprise ID "corp.contoso.com". When a user accesses an app with that ID, VPN will be triggered.-->
+  <EdpModeId>corp.contoso.com</EdpModeId>  
+  <RememberCredentials>true</RememberCredentials>  
+  
+  <!--Always On is turned off, and triggering VPN for the apps and domain name specified earlier in the profile will not occur if the user is connected to the trusted network "contoso.com".-->
+  <AlwaysOn>false</AlwaysOn>  
+  <DnsSuffix>corp.contoso.com</DnsSuffix>  
+  <TrustedNetworkDetection>contoso.com</TrustedNetworkDetection>  
+  <Proxy>  
+    <Manual>  
+      <Server>HelloServer</Server>  
+    </Manual>  
+    <AutoConfigUrl>Helloworld.Com</AutoConfigUrl>  
+  </Proxy>  
+  
+  <!--Device compliance is enabled and an alternate certificate is specified for domain resource authentication.-->
+  <DeviceCompliance>  
+        <Enabled>true</Enabled>  
+        <Sso>  
+            <Enabled>true</Enabled>  
+            <Eku>This is my Eku</Eku>  
+            <IssuerHash>This is my issuer hash</IssuerHash>  
+        </Sso>  
+    </DeviceCompliance>  
+</VPNProfile> 
+```
+
+## Sample plug-in VPN profile
+
+The following sample is a sample plug-in VPN profile. This blob would fall under the ProfileXML node. 
+
+```xml
+<VPNProfile>
+    <ProfileName>TestVpnProfile</ProfileName>
+    <PluginProfile>
+        <ServerUrlList>testserver1.contoso.com;testserver2.contoso..com</ServerUrlList>
+        <PluginPackageFamilyName>JuniperNetworks.JunosPulseVpn_cw5n1h2txyewy</PluginPackageFamilyName>
+        <CustomConfiguration>&lt;pulse-schema&gt;&lt;isSingleSignOnCredential&gt;true&lt;/isSingleSignOnCredential&gt;&lt;/pulse-schema&gt;</CustomConfiguration>
+    </PluginProfile>
+    <Route>
+        <Address>192.168.0.0</Address>
+        <PrefixSize>24</PrefixSize>
+    </Route>
+    <Route>
+        <Address>10.10.0.0</Address>
+        <PrefixSize>16</PrefixSize>
+    </Route>
+    <AppTrigger>
+        <App>
+            <Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
+        </App>
+    </AppTrigger>
+    <AppTrigger>
+        <App>
+            <Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>
+        </App>
+    </AppTrigger>
+    <TrafficFilter>
+        <App>
+            <Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>
+        </App>
+        <Protocol>6</Protocol>
+        <LocalPortRanges>10,20-50,100-200</LocalPortRanges>
+        <RemotePortRanges>20-50,100-200,300</RemotePortRanges>
+        <RemoteAddressRanges>30.30.0.0/16,10.10.10.10-20.20.20.20</RemoteAddressRanges>
+        <!--<RoutingPolicyType>ForceTunnel</RoutingPolicyType>-->
+    </TrafficFilter>
+    <TrafficFilter>
+        <App>
+            <Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
+        </App>
+        <LocalAddressRanges>3.3.3.3/32,1.1.1.1-2.2.2.2</LocalAddressRanges>
+    </TrafficFilter>
+    <TrafficFilter>
+        <App>
+            <Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
+        </App>
+        <Claims>O:SYG:SYD:(A;;CC;;;AU)</Claims>
+        <!--<RoutingPolicyType>SplitTunnel</RoutingPolicyType>-->
+    </TrafficFilter>
+    <DomainNameInformation>
+        <DomainName>corp.contoso.com</DomainName>
+        <DnsServers>1.2.3.4,5.6.7.8</DnsServers>
+        <WebProxyServers>5.5.5.5</WebProxyServers>
+        <AutoTrigger>false</AutoTrigger>
+    </DomainNameInformation>
+    <DomainNameInformation>
+        <DomainName>corp.contoso.com</DomainName>
+        <DnsServers>10.10.10.10,20.20.20.20</DnsServers>
+        <WebProxyServers>100.100.100.100</WebProxyServers>
+    </DomainNameInformation>
+    <!--<EdpModeId>corp.contoso.com</EdpModeId>-->
+    <RememberCredentials>true</RememberCredentials>
+    <AlwaysOn>false</AlwaysOn>
+    <DnsSuffix>corp.contoso.com</DnsSuffix>
+    <TrustedNetworkDetection>contoso.com,test.corp.contoso.com</TrustedNetworkDetection>
+    <Proxy>
+        <Manual>
+            <Server>HelloServer</Server>
+        </Manual>
+        <AutoConfigUrl>Helloworld.Com</AutoConfigUrl>
+    </Proxy>
+</VPNProfile>  
+```
+
+## Apply ProfileXML using Intune
+
+After you configure the settings that you want using ProfileXML, you can create a custom profile in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). After it's created, you deploy this profile to your devices.
+
+1. Sign in to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
+2. Select **Devices** > **Configuration profiles** > **Create profile**.
+3. Enter the following properties:
+
+    - **Platform**: Select **Windows 10 and later**
+    - **Profile**: Select **Templates** > **Custom**.
+
+4. Select **Create**.
+5. In **Basics**, enter the following properties:
+
+    - **Name**: Enter a descriptive name for the profile. Name your profiles so you can easily identify them later.
+    - **Description**: Enter a description for the profile. This setting is optional, but recommended.
+
+6. Select **Next**.
+7. In **Configuration settings**, enter the following properties:
+
+    - **OMA-URI**: Enter `./user/vendor/MSFT/VPNv2/Your_VPN profile name_/ProfileXML`.
+    - **Data type**: Select `String (XML file)`.
+    - **Value**: Browse to, and select your XML file.
+
+    For more information on these settings, see [Use custom settings for Windows devices in Intune](/mem/intune/configuration/custom-settings-windows-10).
+
+8. Select **Next**, and continue configuring the policy. For the specific steps and recommendations, see [Create a profile with custom settings in Intune](/mem/intune/configuration/custom-settings-configure).
+
+## Learn more
+
+- [Create VPN profiles to connect to VPN servers in Intune](/mem/intune/configuration/vpn-settings-configure)
+- [VPNv2 configuration service provider (CSP) reference](/windows/client-management/mdm/vpnv2-csp)
+- [How to Create VPN Profiles in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/dn261200(v=technet.10))
+
+## Related articles
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN security features](vpn-security-features.md)

windows/security/operating-system-security/network-security/vpn/vpn-routing.md

@@ -0,0 +1,55 @@
+---
+ms.date: 05/24/2023
+title: VPN routing decisions
+description: Learn about approaches that either send all data through a VPN or only selected data. The one you choose impacts capacity planning and security expectations.
+ms.topic: conceptual
+---
+# VPN routing decisions
+
+Network routes are required for the stack to understand which interface to use for outbound traffic. One of the most important decision points for VPN configuration is whether you want to send all the data through VPN (*force tunnel*) or only some data through the VPN (*split tunnel*). The decision impacts the configuration, capacity planning, and security expectations from the connection.
+
+## Split tunnel configuration
+
+In a split tunnel configuration, routes can be specified to go over VPN and all other traffic will go over the physical interface.
+
+Routes can be configured using the `VPNv2/<ProfileName>/RouteList` setting in the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
+
+For each route item in the list, you can configure the following options:
+
+- **Address**: `VPNv2/<ProfileName>/RouteList/<routeRowId>/Address`
+- **Prefix size**: `VPNv2/<ProfileName>/RouteList/<routeRowId>/Prefix`
+- **Exclusion route**: V`VPNv2/<ProfileName>/RouteList/<routeRowId>/ExclusionRoute`
+
+With Windows VPN, you can specify exclusion routes that shouldn't go over the physical interface.
+
+Routes can also be added at connect time through the server for UWP VPN apps.  
+
+## Force tunnel configuration
+
+In a force tunnel configuration, all traffic will go over VPN. Force tunnel is the default configuration, and takes effect when no routes are specified.
+
+The only implication of force tunnel is the manipulation of routing entries: VPN V4 and V6 default routes (for example *0.0.0.0/0*) are added to the routing table with a lower metric than ones for other interfaces. This configuration sends traffic through the VPN as long as there isn't a specific route on the physical interface:
+
+- For built-in VPN, the decision is controlled using the MDM setting `VPNv2/ProfileName/NativeProfile/RoutingPolicyType`
+- For a UWP VPN plug-in, the app controls the property. If the VPN plug-in indicates the default route for IPv4 and IPv6 as the only two Inclusion routes, the VPN platform marks the connection as Force Tunneled
+
+## Configure routing
+
+See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
+
+When you configure a VPN profile in Microsoft Intune, you can enable split tunnel configuration:
+
+![split tunnel.](images/vpn-split.png)
+
+Once enabled, you can add the routes that should use the VPN connection.
+
+## Related articles
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN security features](vpn-security-features.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/vpn/vpn-security-features.md

@@ -0,0 +1,68 @@
+---
+title: VPN security features
+description: Learn about security features for VPN, including LockDown VPN and traffic filters.
+ms.date: 05/24/2023
+ms.topic: conceptual
+---
+
+# VPN security features
+
+## Hyper-V based containers and VPN
+
+Windows supports different kinds of Hyper-V based containers, like Microsoft Defender Application Guard and Windows Sandbox. When you use a third party VPN solution, the Hyper-V based containers may not be able to seamlessly connect to the internet, and configuration changes may be needed to resolve connectivity issues.
+
+For example, read about the workaround for Cisco AnyConnect VPN: [Cisco AnyConnect Secure Mobility Client Administrator Guide: Connectivity issues with VM-based subsystems](https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect410/administration/guide/b-anyconnect-admin-guide-4-10/troubleshoot-anyconnect.html#Cisco_Task_in_List_GUI.dita_3a9a8101-f034-4e9b-b24a-486ee47b5e9f).
+
+## Traffic Filters
+
+Traffic Filters enables organizations to decide what traffic is allowed into the corporate network based on policy. IT admins can use Traffic Filters to apply interface-specific firewall rules to the VPN Interface.
+
+There are two types of Traffic Filter rules:
+
+- **App-based rules** consist of a list of applications that can be marked to only allow traffic originating from the apps to the VPN interface
+- **Traffic-based rules** consist of 5-tuple policies (ports, addresses, protocol) that can be specified to only allow traffic matching the rules to go through the VPN interface
+
+There can be sets of rules linked by *OR*. Within each set, there can be app-based rules and traffic-based rules.\
+All the properties within the set are linked by *AND*. The rules can be applied at a per-app level or a per-device level.
+
+For example, an IT admin could define rules that specify:
+
+- An *HR App* is allowed to go through the VPN and only access port *4545*
+- The *Finance apps* are allowed to through the VPN and only access the Remote IP ranges of *10.10.0.40 - 10.10.0.201* on port *5889*
+- All other apps on the device can only access ports *80* or *443*
+
+## Configure traffic filters
+
+See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
+
+The following image shows the interface to configure traffic rules in a VPN Profile configuration policy, using Microsoft Intune.
+
+:::image type="content" source="images/vpn-traffic-rules.png" alt-text="VPN profile creation from Microsoft Intune admin center." lightbox="images/vpn-traffic-rules.png":::
+
+## LockDown VPN
+
+A VPN profile configured with LockDown secures the device to only allow network traffic over the VPN interface. It has the following features:
+
+- The system attempts to always keep the VPN connected
+- The user can't disconnect the VPN connection
+- The user can't delete or modify the VPN profile
+- The VPN LockDown profile uses forced tunnel connection
+- If the VPN connection isn't available, outbound network traffic is blocked
+- Only one VPN LockDown profile is allowed on a device
+
+> [!NOTE]
+> For built-in VPN, LockDown VPN is only available for the Internet Key Exchange version 2 (IKEv2) connection type.
+
+> [!CAUTION]
+> Be careful when deploying LockDown VPN, as the resultant connection won't be able to send or receive any network traffic without the VPN connection being established.
+
+## Related articles
+
+- [VPN technical guide](vpn-guide.md)
+- [VPN connection types](vpn-connection-type.md)
+- [VPN routing decisions](vpn-routing.md)
+- [VPN authentication options](vpn-authentication.md)
+- [VPN and conditional access](vpn-conditional-access.md)
+- [VPN name resolution](vpn-name-resolution.md)
+- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
+- [VPN profile options](vpn-profile-options.md)

windows/security/operating-system-security/network-security/windows-firewall/TOC.yml

@@ -0,0 +1,252 @@
+items:
+  - name: Overview
+    href: windows-firewall-with-advanced-security.md
+  - name: Plan deployment
+    items: 
+      - name: Design guide
+        href: windows-firewall-with-advanced-security-design-guide.md
+      - name: Design process
+        href: understanding-the-windows-firewall-with-advanced-security-design-process.md
+      - name: Implementation goals
+        items: 
+          - name: Identify implementation goals
+            href: identifying-your-windows-firewall-with-advanced-security-deployment-goals.md
+          - name: Protect devices from unwanted network traffic
+            href: protect-devices-from-unwanted-network-traffic.md
+          - name: Restrict access to only trusted devices
+            href: restrict-access-to-only-trusted-devices.md
+          - name: Require encryption
+            href: require-encryption-when-accessing-sensitive-network-resources.md
+          - name: Restrict access
+            href: restrict-access-to-only-specified-users-or-devices.md
+      - name: Implementation designs
+        items: 
+          - name: Mapping goals to a design
+            href: mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md
+          - name: Basic firewall design
+            href: basic-firewall-policy-design.md
+            items: 
+              - name: Basic firewall design example
+                href: firewall-policy-design-example.md
+          - name: Domain isolation design
+            href: domain-isolation-policy-design.md
+            items: 
+              - name: Domain isolation design example
+                href: domain-isolation-policy-design-example.md
+          - name: Server isolation design
+            href: server-isolation-policy-design.md
+            items: 
+              - name: Server Isolation design example
+                href: server-isolation-policy-design-example.md
+          - name: Certificate-based isolation design
+            href: certificate-based-isolation-policy-design.md
+            items: 
+              - name: Certificate-based Isolation design example
+                href: certificate-based-isolation-policy-design-example.md
+      - name: Design planning
+        items: 
+          - name: Planning your design
+            href: planning-your-windows-firewall-with-advanced-security-design.md
+          - name: Planning settings for a basic firewall policy
+            href: planning-settings-for-a-basic-firewall-policy.md
+          - name: Planning domain isolation zones
+            items: 
+              - name: Domain isolation zones
+                href: planning-domain-isolation-zones.md
+              - name: Exemption list
+                href: exemption-list.md
+              - name: Isolated domain
+                href: isolated-domain.md
+              - name: Boundary zone
+                href: boundary-zone.md
+              - name: Encryption zone
+                href: encryption-zone.md
+          - name: Planning server isolation zones
+            href: planning-server-isolation-zones.md
+          - name: Planning certificate-based authentication
+            href: planning-certificate-based-authentication.md
+            items: 
+              - name: Documenting the Zones
+                href: documenting-the-zones.md
+              - name: Planning group policy deployment for your isolation zones
+                href: planning-group-policy-deployment-for-your-isolation-zones.md
+                items: 
+                  - name: Planning isolation groups for the zones
+                    href: planning-isolation-groups-for-the-zones.md
+                  - name: Planning network access groups
+                    href: planning-network-access-groups.md
+                  - name: Planning the GPOs
+                    href: planning-the-gpos.md
+                    items: 
+                      - name: Firewall GPOs
+                        href: firewall-gpos.md
+                        items: 
+                          - name: GPO_DOMISO_Firewall
+                            href: gpo-domiso-firewall.md
+                      - name: Isolated domain GPOs
+                        href: isolated-domain-gpos.md
+                        items: 
+                          - name: GPO_DOMISO_IsolatedDomain_Clients
+                            href: gpo-domiso-isolateddomain-clients.md
+                          - name: GPO_DOMISO_IsolatedDomain_Servers
+                            href: gpo-domiso-isolateddomain-servers.md
+                      - name: Boundary zone GPOs
+                        href: boundary-zone-gpos.md
+                        items: 
+                          - name: GPO_DOMISO_Boundary
+                            href: gpo-domiso-boundary.md
+                      - name: Encryption zone GPOs
+                        href: encryption-zone-gpos.md
+                        items: 
+                          - name: GPO_DOMISO_Encryption
+                            href: gpo-domiso-encryption.md
+                      - name: Server isolation GPOs
+                        href: server-isolation-gpos.md
+                  - name: Planning GPO deployment
+                    href: planning-gpo-deployment.md
+      - name: Planning to deploy
+        href: planning-to-deploy-windows-firewall-with-advanced-security.md
+  - name: Deployment guide
+    items: 
+      - name: Deployment overview
+        href: windows-firewall-with-advanced-security-deployment-guide.md
+      - name: Implementing your plan
+        href: implementing-your-windows-firewall-with-advanced-security-design-plan.md
+      - name: Basic firewall deployment
+        items: 
+          - name: "Checklist: Implementing a basic firewall policy design"
+            href: checklist-implementing-a-basic-firewall-policy-design.md
+      - name: Domain isolation deployment
+        items: 
+          - name: "Checklist: Implementing a Domain Isolation Policy Design"
+            href: checklist-implementing-a-domain-isolation-policy-design.md
+      - name: Server isolation deployment
+        items: 
+          - name: "Checklist: Implementing a Standalone Server Isolation Policy Design"
+            href: checklist-implementing-a-standalone-server-isolation-policy-design.md
+      - name: Certificate-based authentication
+        items: 
+          - name: "Checklist: Implementing a Certificate-based Isolation Policy Design"
+            href: checklist-implementing-a-certificate-based-isolation-policy-design.md
+  - name: Best practices
+    items: 
+      - name: Configuring the firewall
+        href: best-practices-configuring.md
+      - name: Securing IPsec
+        href: securing-end-to-end-ipsec-connections-by-using-ikev2.md
+      - name: PowerShell
+        href: windows-firewall-with-advanced-security-administration-with-windows-powershell.md
+      - name: Isolating Microsoft Store Apps on Your Network
+        href: isolating-apps-on-your-network.md
+  - name: How-to
+    items: 
+      - name: Add Production devices to the membership group for a zone
+        href: add-production-devices-to-the-membership-group-for-a-zone.md
+      - name: Add test devices to the membership group for a zone
+        href: add-test-devices-to-the-membership-group-for-a-zone.md
+      - name: Assign security group filters to the GPO
+        href: assign-security-group-filters-to-the-gpo.md
+      - name: Change rules from request to require mode
+        href: Change-Rules-From-Request-To-Require-Mode.Md
+      - name: Configure authentication methods
+        href: Configure-authentication-methods.md
+      - name: Configure data protection (Quick Mode) settings
+        href: configure-data-protection-quick-mode-settings.md
+      - name: Configure Group Policy to autoenroll and deploy certificates
+        href: configure-group-policy-to-autoenroll-and-deploy-certificates.md
+      - name: Configure key exchange (main mode) settings
+        href: configure-key-exchange-main-mode-settings.md
+      - name: Configure the rules to require encryption
+        href: configure-the-rules-to-require-encryption.md
+      - name: Configure the Windows Firewall log
+        href: configure-the-windows-firewall-log.md
+      - name: Configure the workstation authentication certificate template
+        href: configure-the-workstation-authentication-certificate-template.md
+      - name: Configure Windows Firewall to suppress notifications when a program is blocked
+        href: configure-windows-firewall-to-suppress-notifications-when-a-program-is-blocked.md
+      - name: Confirm that certificates are deployed correctly
+        href: confirm-that-certificates-are-deployed-correctly.md
+      - name: Copy a GPO to create a new GPO
+        href: copy-a-gpo-to-create-a-new-gpo.md
+      - name: Create a Group Account in Active Directory
+        href: create-a-group-account-in-active-directory.md
+      - name: Create a Group Policy Object
+        href: create-a-group-policy-object.md
+      - name: Create an authentication exemption list rule
+        href: create-an-authentication-exemption-list-rule.md
+      - name: Create an authentication request rule
+        href: create-an-authentication-request-rule.md
+      - name: Create an inbound ICMP rule
+        href: create-an-inbound-icmp-rule.md
+      - name: Create an inbound port rule
+        href: create-an-inbound-port-rule.md
+      - name: Create an inbound program or service rule
+        href: create-an-inbound-program-or-service-rule.md
+      - name: Create an outbound port rule
+        href: create-an-outbound-port-rule.md
+      - name: Create an outbound program or service rule
+        href: create-an-outbound-program-or-service-rule.md
+      - name: Create inbound rules to support RPC
+        href: create-inbound-rules-to-support-rpc.md
+      - name: Create WMI filters for the GPO
+        href: create-wmi-filters-for-the-gpo.md
+      - name: Create Windows Firewall rules in Intune
+        href: create-windows-firewall-rules-in-intune.md
+      - name: Enable predefined inbound rules
+        href: enable-predefined-inbound-rules.md
+      - name: Enable predefined outbound rules
+        href: enable-predefined-outbound-rules.md
+      - name: Exempt ICMP from authentication
+        href: exempt-icmp-from-authentication.md
+      - name: Link the GPO to the domain
+        href: link-the-gpo-to-the-domain.md
+      - name: Modify GPO filters
+        href: modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md
+      - name: Open IP security policies
+        href: open-the-group-policy-management-console-to-ip-security-policies.md
+      - name: Open Group Policy
+        href: open-the-group-policy-management-console-to-windows-firewall.md
+      - name: Open Group Policy
+        href: open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md
+      - name: Open Windows Firewall
+        href: open-windows-firewall-with-advanced-security.md
+      - name: Restrict server access
+        href: restrict-server-access-to-members-of-a-group-only.md
+      - name: Enable Windows Firewall
+        href: turn-on-windows-firewall-and-configure-default-behavior.md
+      - name: Verify Network Traffic
+        href: verify-that-network-traffic-is-authenticated.md
+  - name: References
+    items: 
+      - name: "Checklist: Creating Group Policy objects"
+        href: checklist-creating-group-policy-objects.md
+      - name: "Checklist: Creating inbound firewall rules"
+        href: checklist-creating-inbound-firewall-rules.md
+      - name: "Checklist: Creating outbound firewall rules"
+        href: checklist-creating-outbound-firewall-rules.md
+      - name: "Checklist: Configuring basic firewall settings"
+        href: checklist-configuring-basic-firewall-settings.md
+      - name: "Checklist: Configuring rules for the isolated domain"
+        href: checklist-configuring-rules-for-the-isolated-domain.md
+      - name: "Checklist: Configuring rules for the boundary zone"
+        href: checklist-configuring-rules-for-the-boundary-zone.md
+      - name: "Checklist: Configuring rules for the encryption zone"
+        href: checklist-configuring-rules-for-the-encryption-zone.md
+      - name: "Checklist: Configuring rules for an isolated server zone"
+        href: checklist-configuring-rules-for-an-isolated-server-zone.md
+      - name: "Checklist: Configuring rules for servers in a standalone isolated server zone"
+        href: checklist-configuring-rules-for-servers-in-a-standalone-isolated-server-zone.md
+      - name: "Checklist: Creating rules for clients of a standalone isolated server zone"
+        href: checklist-creating-rules-for-clients-of-a-standalone-isolated-server-zone.md
+      - name: "Appendix A: Sample GPO template files for settings used in this guide"
+        href: appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md
+  - name: Troubleshooting
+    items: 
+      - name: Troubleshooting UWP app connectivity issues in Windows Firewall
+        href: troubleshooting-uwp-firewall.md
+      - name: Filter origin audit log improvements
+        href: filter-origin-documentation.md
+      - name: Quarantine behavior
+        href: quarantine.md
+      - name: Firewall settings lost on upgrade
+        href: firewall-settings-lost-on-upgrade.md

windows/security/operating-system-security/network-security/windows-firewall/add-production-devices-to-the-membership-group-for-a-zone.md

@@ -0,0 +1,77 @@
+---
+title: Add Production Devices to the Membership Group for a Zone 
+description: Learn how to add production devices to the membership group for a zone and refresh the group policy on the devices in the membership group.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Add Production Devices to the Membership Group for a Zone
+
+
+
+After you test the GPOs for your design on a small set of devices, you can deploy them to the production devices.
+
+**Caution**  
+For GPOs that contain connection security rules that prevent unauthenticated connections, ensure you set the rules to request, not require, authentication during testing. After you deploy the GPO and confirm that all of your devices are successfully communicating by using authenticated IPsec, then you can modify the GPO to require authentication. Don't change the boundary zone GPO to require mode.
+
+ 
+
+The method discussed in this guide uses the **Domain Computers** built-in group. The advantage of this method is that all new devices that are joined to the domain automatically receive the isolated domain GPO. To define this setting successfully, you must make sure that the WMI filters and security group filters exclude devices that must not receive the GPOs. Use device groups that deny both read and apply Group Policy permissions to the GPOs, such as a group used in the CG\_DOMISO\_NOIPSEC example design. Devices that are members of some zones must also be excluded from applying the GPOs for the main isolated domain. For more information, see the "Prevent members of a group from applying a GPO" section in [Assign Security Group Filters to the GPO](assign-security-group-filters-to-the-gpo.md).
+
+Without such a group (or groups), you must either add devices individually or use the groups containing device accounts that are available to you.
+
+**Administrative credentials**
+
+To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO.
+
+In this topic:
+
+-   [Add the group Domain Devices to the GPO membership group](#to-add-domain-devices-to-the-gpo-membership-group)
+
+-   [Refresh Group Policy on the devices in the membership group](#to-refresh-group-policy-on-a-device)
+
+-   [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
+
+## To add domain devices to the GPO membership group
+
+1.  Open Active Directory Users and Computers.
+
+2.  In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then the container in which you created the membership group.
+
+3.  In the details pane, double-click the GPO membership group to which you want to add computers.
+
+4.  Select the **Members** tab, and then click **Add**.
+
+5.  Type **Domain Computers** in the text box, and then click **OK**.
+
+6.  Click **OK** to close the group properties dialog box.
+
+After a computer is a member of the group, you can force a Group Policy refresh on the computer.
+
+## To refresh Group Policy on a device
+
+From an elevated command prompt, type the following command:
+
+``` syntax
+gpupdate /target:computer /force
+```
+
+After Group Policy is refreshed, you can see which GPOs are currently applied to the computer.
+
+## To see which GPOs are applied to a device
+
+From an elevated command prompt, type the following command:
+
+``` syntax
+gpresult /r /scope:computer
+```
+
+ 
+
+ 
+
+
+
+
+

windows/security/operating-system-security/network-security/windows-firewall/add-test-devices-to-the-membership-group-for-a-zone.md

@@ -0,0 +1,71 @@
+---
+title: Add Test Devices to the Membership Group for a Zone 
+description: Learn how to add devices to the group for a zone to test whether your Windows Defender Firewall with Advanced Security implementation works as expected.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Add Test Devices to the Membership Group for a Zone
+
+
+Before you deploy your rules to large numbers of devices, you must thoroughly test the rules to make sure that communications are working as expected. A misplaced WMI filter or an incorrectly typed IP address in a filter list can easily block communications between devices. Although we recommend that you set your rules to request mode until testing and deployment is complete. We also recommend that you initially deploy the rules to a few devices only to be sure that the correct GPOs are being processed by each device.
+
+Add at least one device of each supported operating system type to each membership group. Make sure every GPO for a specific version of Windows and membership group has a device among the test group. After Group Policy has been refreshed on each test device, check the output of the **gpresult** command to confirm that each device is receiving only the GPOs it's supposed to receive.
+
+**Administrative credentials**
+
+To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO.
+
+In this topic:
+
+-   [Add the test devices to the GPO membership groups](#to-add-test-devices-to-the-gpo-membership-groups)
+
+-   [Refresh Group Policy on the devices in each membership group](#to-refresh-group-policy-on-a-device)
+
+-   [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
+
+## To add test devices to the GPO membership groups
+
+1.  Open Active Directory Users and Computers.
+
+2.  In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then expand the container that holds your membership group account.
+
+3.  In the details pane, double-click the GPO membership group to which you want to add devices.
+
+4.  Select the **Members** tab, and then click **Add**.
+
+5.  Type the name of the device in the text box, and then click **OK**.
+
+6.  Repeat steps 5 and 6 for each extra device account or group that you want to add.
+
+7.  Click **OK** to close the group properties dialog box.
+
+After a device is a member of the group, you can force a Group Policy refresh on the device.
+
+## To refresh Group Policy on a device
+
+From an elevated command prompt, run the following command:
+
+``` syntax
+gpupdate /target:device /force
+```
+
+After Group Policy is refreshed, you can see which GPOs are currently applied to the device.
+
+## To see which GPOs are applied to a device
+
+From an elevated command prompt, run the following command:
+
+``` syntax
+gpresult /r /scope:computer
+```
+
+ 
+
+ 
+
+
+
+
+

windows/security/operating-system-security/network-security/windows-firewall/appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md

@@ -0,0 +1,87 @@
+---
+title: Appendix A Sample GPO Template Files for Settings Used in this Guide 
+description: Use sample template files import an XML file containing customized registry preferences into a Group Policy Object (GPO).
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Appendix A: Sample GPO Template Files for Settings Used in this Guide
+
+
+You can import an XML file containing customized registry preferences into a Group Policy Object (GPO) by using the Preferences feature of the Group Policy Management Console (GPMC).
+
+To manually create the file, build the settings under **Computer Configuration**, **Preferences**, **Windows Settings**, **Registry**. After you have created the settings, drag the container to the desktop. An .xml file is created there.
+
+To import an .xml file to GPMC, drag it and drop it on the **Registry** node under **Computer Configuration**, **Preferences**, **Windows Settings**. If you copy the following sample XML code to a file, and then drag and drop it on the **Registry** node, it creates a **Server and Domain Isolation** collection with the six registry keys discussed in this guide.
+
+The following sample file uses item-level targeting to ensure that the registry keys are applied only on the versions of Windows to which they apply.
+
+>**Note:**  The file shown here is for sample use only. It should be customized to meet the requirements of your organization’s deployment. To customize this file, import it into a test GPO, modify the settings, and then drag the Server and Domain Isolation Settings node to your desktop. The new file will contain all of your customization.
+
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+
+<Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Server and Domain Isolation Settings">
+
+<Registry
+         clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}"
+         name="Enable PMTU Discovery"
+         status="EnablePMTUDiscovery"
+         image="12"
+         changed="2008-05-30 20:37:37"
+         uid="{52C38FD7-A081-404C-A8EA-B24A9614D0B5}"
+         desc="&lt;b&gt;Enable PMTU Discovery&lt;/b&gt;&lt;p&gt;
+            This setting configures whether computers can use PMTU
+            discovery on the network.&lt;p&gt;
+            &lt;b&gt;1&lt;/b&gt; --  Enable&lt;br&gt;
+            &lt;b&gt;0&lt;/b&gt; --  Disable"
+         bypassErrors="1">
+   <Properties
+         action="U"
+         displayDecimal="1"
+         default="0"
+         hive="HKEY_LOCAL_MACHINE"
+         key="System\CurrentControlSet\Services\TCPIP\Parameters"
+         name="EnablePMTUDiscovery" type="REG_DWORD" value="00000001"/>
+</Registry>
+
+<Registry
+         clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}"
+         name="IPsec Default Exemptions (Vista and W2K8)"
+         status="NoDefaultExempt"
+         image="12"
+         changed="2008-05-30 20:33:32"
+         uid="{AE5C505D-283E-4060-9A55-70659DFD56B6}"
+         desc="&lt;b&gt;IPsec Default Exemptions for Windows Server 2008
+            and later&lt;/b&gt;&lt;p&gt;
+            This setting determines which network traffic type is exempt
+            from any IPsec authentication requirements.&lt;p&gt;
+            &lt;b&gt;0&lt;/b&gt;: Exempts multicast, broadcast, RSVP, Kerberos, ISAKMP&lt;br&gt;
+            &lt;b&gt;1&lt;/b&gt;: Exempts multicast, broadcast, ISAKMP&lt;br&gt;
+            &lt;b&gt;2&lt;/b&gt;: Exempts RSVP, Kerberos, ISAKMP&lt;br&gt;
+            &lt;b&gt;3&lt;/b&gt;: Exempts ISAKMP only"
+         bypassErrors="1">
+   <Properties
+         action="U"
+         displayDecimal="1"
+         default="0"
+         hive="HKEY_LOCAL_MACHINE"
+         key="SYSTEM\CurrentControlSet\Services\PolicyAgent"
+         name="NoDefaultExempt"
+         type="REG_DWORD"
+         value="00000003"/>
+   <Filters>
+      <FilterOs
+         bool="AND" not="0"
+         class="NT" version="VISTA"
+         type="NE" edition="NE" sp="NE"/>
+      <FilterOs
+         bool="OR" not="0"
+         class="NT" version="2K8"
+         type="NE" edition="NE" sp="NE"/>
+   </Filters>
+</Registry>
+
+</Collection>
+```

windows/security/operating-system-security/network-security/windows-firewall/assign-security-group-filters-to-the-gpo.md

@@ -0,0 +1,69 @@
+---
+title: Assign Security Group Filters to the GPO 
+description: Learn how to use Group Policy Management MMC to assign security group filters to a GPO to make sure that the GPO is applied to the correct computers.
+ms.prod: windows-client
+ms.collection: 
+  - highpri
+  - tier3
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Assign Security Group Filters to the GPO
+
+
+To make sure that your GPO is applied to the correct computers, use the Group Policy Management MMC snap-in to assign security group filters to the GPO.
+
+>[!IMPORTANT]
+>This deployment guide uses the method of adding the Domain Computers group to the membership group for the main isolated domain after testing is complete and you are ready to go live in production. To make this method work, you must prevent any computer that is a member of either the boundary or encryption zone from applying the GPO for the main isolated domain. For example, on the GPOs for the main isolated domain, deny Read and Apply Group Policy permissions to the membership groups for the boundary and encryption zones.
+
+ 
+
+**Administrative credentials**
+
+To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the relevant GPOs.
+
+In this topic:
+
+-   [Allow members of a group to apply a GPO](#to-allow-members-of-a-group-to-apply-a-gpo)
+
+-   [Prevent members of a group from applying a GPO](#to-prevent-members-of-a-group-from-applying-a-gpo)
+
+## To allow members of a group to apply a GPO
+
+Use the following procedure to add a group to the security filter on the GPO that allows group members to apply the GPO.
+
+1.  Open the Group Policy Management console.
+
+2.  In the navigation pane, find and then click the GPO that you want to modify.
+
+3.  In the details pane, under **Security Filtering**, click **Authenticated Users**, and then click **Remove**.
+
+    >[!NOTE]
+    >You must remove the default permission granted to all authenticated users and computers to restrict the GPO to only the groups you specify. If the GPO contains User settings, and the **Authenticated Users** group is removed, and new security filtering is added using a security group that only contains user accounts, the GPO can fail to apply. Details and various workarounds are mentioned in this [Microsoft blog](https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/Who-broke-my-user-GPOs/ba-p/258781). 
+
+4.  Click **Add**.
+
+5.  In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to apply the GPO, and then click **OK**. If you do not know the name, you can click **Advanced** to browse the list of groups available in the domain.
+
+## To prevent members of a group from applying a GPO 
+
+Use the following procedure to add a group to the security filter on the GPO that prevents group members from applying the GPO. This is typically used to prevent members of the boundary and encryption zones from applying the GPOs for the isolated domain.
+
+1.  Open the Group Policy Management console.
+
+2.  In the navigation pane, find and then click the GPO that you want to modify.
+
+3.  In the details pane, click the **Delegation** tab.
+
+4.  Click **Advanced**.
+
+5.  Under the **Group or user names** list, click **Add**.
+
+6.  In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then click **OK**. If you do not know the name, you can click **Advanced** to browse the list of groups available in the domain.
+
+7.  Select the group in the **Group or user names** list, and then select the box in the **Deny** column for both **Read** and **Apply group policy**.
+
+8.  Click **OK**, and then in the **Windows Security** dialog box, click **Yes**.
+
+9.  The group appears in the list with **Custom** permissions.

windows/security/operating-system-security/network-security/windows-firewall/basic-firewall-policy-design.md

@@ -0,0 +1,63 @@
+---
+title: Basic Firewall Policy Design 
+description: Protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses by using basic firewall policy design.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 12/31/2017
+---
+
+# Basic Firewall Policy Design
+
+
+Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but don't have a host-based firewall enabled on each device in the organization.
+
+The Basic Firewall Policy Design helps you to protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each device in your organization to allow traffic that is required by the programs that are used. Traffic that doesn't match the rules is dropped.
+
+Traffic can be blocked or permitted based on the characteristics of each network packet: its source or destination IP address, its source or destination port numbers, the program on the device that receives the inbound packet, and so on. This design can also be deployed together with one or more of the other designs that add IPsec protection to the network traffic permitted.
+
+Many network administrators don't want to tackle the difficult task of determining all the appropriate rules for every program that is used by the organization, and then maintaining that list over time. In fact, most programs don't require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy:
+
+- On client devices, the default firewall behavior already supports typical client programs. Programs create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another device.
+
+- When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you.
+
+  For example, when you install a server role, the appropriate firewall rules are created and enabled automatically.
+
+- For other standard network behavior, the predefined rules that are built into Windows 11, Windows 10, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, and Windows 7 can easily be configured in a GPO and deployed to the devices in your organization.
+
+  For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols.
+
+With a few exceptions, the firewall can be enabled on all configurations. Therefore, we recommend that you enable the firewall on every device in your organization. The term "device" includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network.
+
+> [!CAUTION]
+> Stopping the service associated with Windows Defender Firewall with Advanced Security is not supported by Microsoft.
+
+By default, in new installations, Windows Defender Firewall with Advanced Security is turned on in Windows Server 2012, Windows 8, and later.
+
+If you turn off the Windows Defender Firewall service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting.
+
+Compatible third-party firewall software can programmatically disable only the parts of Windows Defender Firewall that might need to be disabled for compatibility. This approach is the recommended one for third-party firewalls to coexist with the Windows Defender Firewall; third-party firewalls that comply with this recommendation have the certified logo from Microsoft.
+
+An organization typically uses this design as a first step toward a more comprehensive Windows Defender Firewall design that adds server isolation and domain isolation.
+
+After implementing this design, you'll have centralized management of the firewall rules applied to all devices that are running Windows in your organization.
+
+> [!IMPORTANT] 
+> If you also intend to deploy the [Domain Isolation Policy Design](domain-isolation-policy-design.md), or the [Server Isolation Policy Design](server-isolation-policy-design.md), we recommend that you do the design work for all three designs together, and then deploy in layers that correspond with each design.
+
+The basic firewall design can be applied to devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the firewall settings and rules.
+
+For more information about this design:
+
+- This design coincides with the deployment goal to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md).
+
+- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md).
+
+- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
+
+- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md).
+
+- For a list of detailed tasks that you can use to deploy your basic firewall policy design, see [Checklist: Implementing a Basic Firewall Policy Design](checklist-implementing-a-basic-firewall-policy-design.md).
+
+> [!div class="nextstepaction"]
+> [Domain Isolation Policy Design](domain-isolation-policy-design.md)

windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md

@@ -0,0 +1,179 @@
+---
+title: Best practices for configuring Windows Defender Firewall
+description: Learn about best practices for configuring Windows Defender Firewall
+ms.prod: windows-client
+ms.date: 11/09/2022
+ms.collection: 
+  - highpri
+  - tier3
+ms.topic: article
+---
+
+# Best practices for configuring Windows Defender Firewall
+
+Windows Defender Firewall with Advanced Security provides host-based, two-way
+network traffic filtering and blocks unauthorized network traffic flowing into
+or out of the local device. Configuring your Windows Firewall based on the
+following best practices can help you optimize protection for devices in your
+network. These recommendations cover a wide range of deployments including home
+networks and enterprise desktop/server systems.
+
+To open Windows Firewall, go to the **Start** menu, select **Run**,
+type **WF.msc**, and then select **OK**. See also [Open Windows Firewall](./open-windows-firewall-with-advanced-security.md).
+
+## Keep default settings
+
+When you open the Windows Defender Firewall for the first time, you can see the default settings applicable to the local computer. The Overview panel displays security settings for each type of network to which the device can connect.
+
+![Windows Defender Firewall with Advanced Security first time opening.](images/fw01-profiles.png)
+
+*Figure 1: Windows Defender Firewall*
+
+1. **Domain profile**: Used for networks where there's a system of account authentication against an Active Directory domain controller
+1. **Private profile**: Designed for and best used in private networks such as a home network
+1. **Public profile**: Designed with higher security in mind for public networks, like Wi-Fi hotspots, coffee shops, airports, hotels, or stores
+
+View detailed settings for each profile by right-clicking the top-level **Windows Defender Firewall with Advanced Security** node in the left pane and then selecting **Properties**.
+
+Maintain the default settings in Windows Defender
+Firewall whenever possible. These settings have been designed to secure your device for use in most network scenarios. One key example is the default Block behavior for Inbound connections.
+
+![A screenshot of a cell phone Description automatically generated.](images/fw03-defaults.png)
+
+*Figure 2: Default inbound/outbound settings*
+
+> [!IMPORTANT]
+> To maintain maximum security, do not change the default Block setting for inbound connections.
+
+For more on configuring basic firewall settings, see [Turn on Windows Firewall and Configure Default Behavior](./turn-on-windows-firewall-and-configure-default-behavior.md) and [Checklist: Configuring Basic Firewall Settings](./checklist-configuring-basic-firewall-settings.md).
+
+## Understand rule precedence for inbound rules
+
+In many cases, a next step for administrators will be to customize these profiles using rules (sometimes called filters) so that they can work with user apps or other types of software. For example, an administrator or user may choose to add a rule to accommodate a program, open a port or protocol, or allow a predefined type of traffic.
+
+This rule-adding task can be accomplished by right-clicking either **Inbound Rules** or **Outbound Rules**, and selecting **New Rule**. The interface for adding a new rule looks like this:
+
+![Rule creation wizard.](images/fw02-createrule.png)
+
+*Figure 3: Rule Creation Wizard*
+
+> [!NOTE]
+>This article does not cover step-by-step rule configuration. See the [Windows Firewall with Advanced Security Deployment Guide](./windows-firewall-with-advanced-security-deployment-guide.md) for general guidance on policy creation.
+
+In many cases, allowing specific types of inbound traffic will be required for applications to function in the network. Administrators should keep the following rule precedence behaviors in mind when allowing these inbound exceptions.
+
+1. Explicitly defined allow rules will take precedence over the default block setting.
+1. Explicit block rules will take precedence over any conflicting allow rules.
+1. More specific rules will take precedence over less specific rules, except if there are explicit block rules as mentioned in 2. (For example, if the parameters of rule 1 include an IP address range, while the parameters of rule 2 include a single IP host address, rule 2 will take precedence.)
+
+Because of 1 and 2, it's important that, when designing a set of policies, you make sure that there are no other explicit block rules in place that could inadvertently overlap, thus preventing the traffic flow you wish to allow.
+
+A general security best practice when creating inbound rules is to be as specific as possible. However, when new rules must be made that use ports or IP addresses, consider using consecutive ranges or subnets instead of individual addresses or ports where possible. This approach avoids creation of multiple filters under the hood, reduces complexity, and helps to avoid performance degradation.
+
+> [!NOTE]
+> Windows Defender Firewall does not support traditional weighted, administrator-assigned rule ordering. An effective policy set with expected behaviors can be created by keeping in mind the few, consistent, and logical rule behaviors described above.
+
+## Create rules for new applications before first launch
+
+### Inbound allow rules
+
+When first installed, networked applications and services issue a listen call specifying the protocol/port information required for them to function properly. As there's a default block action in Windows Defender Firewall, it's necessary to create inbound exception rules to allow this traffic. It's common for the app or the app installer itself to add this firewall rule. Otherwise, the user (or firewall admin on behalf of the user) needs to manually create a rule.
+
+If there's no active application or administrator-defined allow rule(s), a dialog box will prompt the user to either allow or block an application's packets the first time the app is launched or tries to communicate in the network.
+
+- If the user has admin permissions, they'll be prompted. If they respond *No* or cancel the prompt, block rules will be created. Two rules are typically created, one each for TCP and UDP traffic.
+
+- If the user isn't a local admin, they won't be prompted. In most cases, block rules will be created.
+
+In either of the scenarios above, once these rules are added they must be deleted in order to generate the prompt again. If not, the traffic will continue to be blocked.
+
+> [!NOTE]
+> The firewall's default settings are designed for security. Allowing all inbound connections by default introduces the network to various threats. Therefore, creating exceptions for inbound connections from third-party software should be determined by trusted app developers, the user, or the admin on behalf of the user. 
+
+### Known issues with automatic rule creation
+
+When designing a set of firewall policies for your network, it's a best practice to configure allow rules for any networked applications deployed on the host. Having these rules in place before the user first launches the application will help ensure a seamless experience.
+
+The absence of these staged rules doesn't necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime require user interaction and administrative privilege. If the device is expected to be used by non-administrative users, you should follow best practices and provide these rules before the application's first launch to avoid unexpected networking issues.
+
+To determine why some applications are blocked from communicating in the network, check for the following instances:
+
+1. A user with sufficient privileges receives a query notification advising them that the application needs to make a change to the firewall policy. Not fully understanding the prompt, the user cancels or dismisses the prompt.
+1. A user lacks sufficient privileges and is therefore not prompted to allow the application to make the appropriate policy changes.
+1. Local Policy Merge is disabled, preventing the application or network service from creating local rules.
+
+Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
+
+![Windows Firewall prompt.](images/fw04-userquery.png)
+
+*Figure 4: Dialog box to allow access*
+
+See also [Checklist: Creating Inbound Firewall Rules](./checklist-creating-inbound-firewall-rules.md).
+
+## Establish local policy merge and application rules
+
+Firewall rules can be deployed:
+
+1. Locally using the Firewall snap-in (**WF.msc**)
+1. Locally using PowerShell 
+1. Remotely using Group Policy if the device is a member of an Active Directory Name, System  Center Configuration Manager, or Intune (using workplace join)
+
+Rule merging settings control how rules from different policy sources can be combined. Administrators can configure different merge behaviors for Domain, Private, and Public profiles.
+
+The rule-merging settings either allow or prevent local administrators from creating their own firewall rules in addition to those rules obtained from Group Policy.
+
+![Customize settings.](images/fw05-rulemerge.png)
+
+*Figure 5: Rule merging setting*
+
+> [!TIP]
+> In the firewall [configuration service provider](/windows/client-management/mdm/firewall-csp), the equivalent setting is *AllowLocalPolicyMerge*. This setting can be found under each respective profile node, *DomainProfile*, *PrivateProfile*, and *PublicProfile*.
+
+If merging of local policies is disabled, centralized deployment of rules is required for any app that needs inbound connectivity.
+
+Administrators may disable *LocalPolicyMerge* in high-security environments to maintain tighter control over endpoints. This setting can impact some applications and services that automatically generate a local firewall policy upon installation as discussed above. For these types of apps and services to work, admins should push rules centrally via group policy (GP), Mobile Device
+Management (MDM), or both (for hybrid or co-management environments).
+
+[Firewall CSP](/windows/client-management/mdm/firewall-csp) and [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider) also have settings that can affect rule merging.
+
+As a best practice, it's important to list and log such apps, including the network ports used for communications. Typically, you can find what ports must be open for a given service on the app's website. For more complex or customer application deployments, a more thorough analysis may be needed using network packet capture tools.
+
+In general, to maintain maximum security, admins should only push firewall exceptions for apps and services determined to serve legitimate purposes.
+
+> [!NOTE]
+> The use of wildcard patterns, such as *C:\*\\teams.exe* is not supported in application rules. We currently only support rules created using the full path to the application(s).
+
+## Know how to use "shields up" mode for active attacks
+
+An important firewall feature you can use to mitigate damage during an active attack is the "shields up" mode. It's an informal term referring to an easy method a firewall administrator can use to temporarily increase security in the face of an active attack.
+
+Shields up can be achieved by checking **Block all
+incoming connections, including those in the list of allowed apps** setting found in either the Windows Settings app or the legacy file *firewall.cpl*.
+
+![Incoming connections.](images/fw06-block.png)
+
+*Figure 6: Windows settings App/Windows Security/Firewall Protection/Network Type*
+
+![Firewall cpl.](images/fw07-legacy.png)
+
+*Figure 7: Legacy firewall.cpl*
+
+By default, the Windows Defender Firewall will block everything unless there's an exception rule created. This setting overrides the exceptions. 
+
+For example, the Remote Desktop feature automatically creates firewall rules when enabled. However, if there's an active exploit using multiple ports and services on a host, you can, instead of disabling individual rules, use the shields up mode to block all inbound connections, overriding previous exceptions, including the rules for Remote Desktop. The Remote Desktop rules remain intact but remote access won't work as long as shields up is activated.
+
+Once the emergency is over, uncheck the setting to restore regular network traffic.
+
+## Create outbound rules
+
+What follows are a few general guidelines for configuring outbound rules.
+
+- The default configuration of Blocked for Outbound rules can be considered for certain highly secure environments. However, the Inbound rule configuration should never be changed in a way that Allows traffic by default
+- It's recommended to Allow Outbound by default for most deployments for the sake of simplification around app deployments, unless the enterprise prefers tight security controls over ease-of-use
+- In high security environments, an inventory of all enterprise-spanning apps must be taken and logged by the administrator or administrators. Records must include whether an app used requires network connectivity. Administrators will need to create new rules specific to each app that needs network connectivity and push those rules centrally, via group policy (GP), Mobile Device Management (MDM), or both (for hybrid or co-management environments)
+
+For tasks related to creating outbound rules, see [Checklist: Creating Outbound Firewall Rules](./checklist-creating-outbound-firewall-rules.md).
+
+## Document your changes
+
+When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.

windows/security/operating-system-security/network-security/windows-firewall/boundary-zone-gpos.md

@@ -0,0 +1,22 @@
+---
+title: Boundary Zone GPOs 
+description: Learn about GPOs to create that must align with the group you create for the boundary zone in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Boundary Zone GPOs
+
+
+All the devices in the boundary zone are added to the group CG\_DOMISO\_Boundary. You must create multiple GPOs to align with this group, one for each operating system that you have in your boundary zone. This group is granted Read and Apply permissions in Group Policy on the GPOs described in this section.
+
+>**Note:**  If you are designing GPOs for at least Windows Vista or Windows Server 2008, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any devices that are incorrectly assigned to more than one group.
+
+This recommendation means that you create a GPO for a boundary group for a specific operating system by copying and pasting the corresponding GPO for the isolated domain, and then modifying the new copy to provide the behavior required in the boundary zone.
+
+The boundary zone GPOs discussed in this guide are only for server versions of Windows because client devices aren't expected to participate in the boundary zone. If the need for one occurs, either create a new GPO for that version of Windows or expand the WMI filter attached to one of the existing boundary zone GPOs to make it apply to the client version of Windows.
+
+In the Woodgrove Bank example, only the GPO settings for a Web service on at least Windows Server 2008 are discussed.
+
+-   [GPO\_DOMISO\_Boundary\_WS2008](gpo-domiso-boundary.md)

windows/security/operating-system-security/network-security/windows-firewall/boundary-zone.md

@@ -0,0 +1,57 @@
+---
+title: Boundary Zone 
+description: Learn how a boundary zone supports devices that must receive traffic from beyond an isolated domain in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Boundary Zone
+ 
+
+In most organizations, some devices can receive network traffic from devices that aren't part of the isolated domain, and therefore can't authenticate. To accept communications from untrusted devices, create a boundary zone within your isolated domain.
+
+Devices in the boundary zone are trusted devices that can accept communication requests both from other isolated domain member devices and from untrusted devices. Boundary zone devices try to authenticate any incoming request by using IPsec, initiating an IKE negotiation with the originating device.
+
+The GPOs you build for the boundary zone include IPsec or connection security rules that request authentication for both inbound and outbound network connections, but don't require it.
+
+These boundary zone devices might receive unsolicited inbound communications from untrusted devices that use plaintext and must be carefully managed and secured in other ways. Mitigating this extra risk is an important part of deciding whether to add a device to the boundary zone. For example, completing a formal business justification process before adding each device to the boundary zone minimizes the extra risk. The following illustration shows a sample process that can help make such a decision.
+
+![design flowchart.](images/wfas-designflowchart1.gif)
+
+The goal of this process is to determine whether the risk of adding a device to a boundary zone can be mitigated to a level that makes it acceptable to the organization. Ultimately, if the risk can't be mitigated, membership must be denied.
+
+You must create a group in Active Directory to contain the members of the boundary zones. The settings and rules for the boundary zone are typically similar to those settings and rules for the isolated domain, and you can save time and effort by copying those GPOs to serve as a starting point. The primary difference is that the authentication connection security rule must be set to request authentication for both inbound and outbound traffic, instead of requiring inbound authentication and requesting outbound authentication as used by the isolated domain.
+
+ [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section discusses creation of the group and how to link it to the GPOs that apply the rules to members of the group.
+
+## GPO settings for boundary zone servers running at least Windows Server 2008
+
+
+The boundary zone GPO for devices running at least Windows Server 2008 should include the following components:
+
+-   IPsec default settings that specify the following options:
+
+    1.  Exempt all ICMP traffic from IPsec.
+
+    2.  Key exchange (main mode) security methods and algorithm. We recommend that you use at least DH4, AES, and SHA2 in your settings. Use the strongest algorithm combinations that are common to all your supported operating systems.
+
+    3.  Data protection (quick mode) algorithm combinations. We recommend that you don't include DES or MD5 in any setting. They're included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems.
+
+        If any NAT devices are present on your networks, use ESP encapsulation. If isolated domain members must communicate with hosts in the encryption zone, ensure that you include algorithms that are compatible with the requirements of the encryption mode policies.
+
+    4.  Authentication methods. Include at least device-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then you must also include user-based Kerberos V5 authentication as an optional authentication method. Likewise, if any of your domain isolation members can't use Kerberos V5, you must include certificate-based authentication as an optional authentication method.
+
+-   The following connection security rules:
+
+    -   A connection security rule that exempts all devices on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, if applicable in your environment.
+
+    -   A connection security rule, from **Any IP address** to **Any IP address**, that requests inbound and outbound authentication.
+
+-   A registry policy that includes the following values:
+
+    -   Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\\System\\CurrentControlSet\\Services\\TCPIP\\Parameters\\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) sets the value to **1**.
+
+    >**Note:**  For a sample template for these registry settings, see [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md)
+
+**Next:**[Encryption Zone](encryption-zone.md)

windows/security/operating-system-security/network-security/windows-firewall/certificate-based-isolation-policy-design-example.md

@@ -0,0 +1,46 @@
+---
+title: Certificate-based Isolation Policy Design Example 
+description: This example uses a fictitious company to illustrate certificate-based isolation policy design in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Certificate-based Isolation Policy Design Example
+
+
+This design example continues to use the fictitious company Woodgrove Bank, as described in the sections [Firewall Policy Design Example](firewall-policy-design-example.md), [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md), and [Server Isolation Policy Design Example](server-isolation-policy-design-example.md).
+
+One of the servers that must be included in the domain isolation environment is a device running UNIX that supplies other information to the WGBank dashboard program running on the client devices. This device sends updated information to the WGBank front-end servers as it becomes available, so it's considered unsolicited inbound traffic to the devices that receive this information.
+
+## Design requirements
+
+One possible solution to this design example is to include an authentication exemption rule in the GPO applied to the WGBank front-end servers. This rule would instruct the front-end servers to accept traffic from the non-Windows device even though it can't authenticate.
+
+A more secure solution, and the one selected by Woodgrove Bank, is to include the non-Windows device in the domain isolation design. Because it can't join an Active Directory domain, Woodgrove Bank chose to use certificate-based authentication. Certificates are cryptographically protected documents, encrypted in such a way that their origin can be positively confirmed.
+
+In this case, Woodgrove Bank used Active Directory Certificate Services to create the appropriate certificate. They might also have acquired and installed a certificate from a third-party commercial certification authority. They then used Group Policy to deploy the certificate to the front-end servers. The GPOs applied to the front-end servers also include updated connection security rules that permit certificate-based authentication in addition to Kerberos V5 authentication. They then manually installed the certificate on the UNIX server.
+
+The UNIX server is configured with firewall and IPsec connection security rules using the tools that are provided by the operating system vendor. Those rules specify that authentication is performed by using the certificate.
+
+The creation of the IPsec connection security rules for a non-Windows device is beyond the scope of this document, but support for a certificate that can be used to authenticate such a non-Windows device by using the standard IPsec protocols is the subject of this design.
+
+The non-Windows device can be effectively made a member of the boundary zone or the encryption zone based on the IPsec rules applied to the device. The only constraint is that the main mode and quick mode encryption algorithms supported by the UNIX device must also be supported by the Windows-based devices with which it communicates.
+
+**Other traffic notes:**
+
+-   None of the capabilities of the other designs discussed in this guide are compromised by the use of certificate authentication by a non-Windows device.
+
+## Design details
+
+Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the devices in their organization.
+
+The inclusion of one or more non-Windows devices to the network requires only a simple addition to the GPOs for devices that must communicate with the non-Windows device. The addition is allowing certificate-based authentication in addition to the Active Directory–supported Kerberos V5 authentication. This certificate-based authoring doesn't require including new rules, just adding certificate-based authentication as an option to the existing rules.
+
+When multiple authentication methods are available, two negotiating devices agree on the first one in their lists that match. Because most of the devices in Woodgrove Bank's network run Windows, Kerberos V5 is listed as the first authentication method in the rules. Certificate-based authentication is added as an alternate authentication type.
+
+With the help of the Active Directory Users and Computers snap-in, Woodgrove Bank created a group named NAG\_COMPUTER\_WGBUNIX. They then added the device accounts to this group for Windows devices that need to communicate with the non-Windows devices. If all the devices in the isolated domain need to be able to access the non-Windows devices, then the **Domain Computers** group can be added to the group as a member.
+
+Woodgrove Bank then created a GPO that contains the certificate, and then attached security group filters to the GPO that allow read and apply permissions to only members of the NAG\_COMPUTER\_WGBUNIX group. The GPO places the certificate in the **Local Computer / Personal / Certificates** certificate store. The certificate used must chain back to a certificate that is in the **Trusted Root Certification Authorities** store on the local device.
+
+**Next:** [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)

windows/security/operating-system-security/network-security/windows-firewall/certificate-based-isolation-policy-design.md

@@ -0,0 +1,34 @@
+---
+title: Certificate-based Isolation Policy Design 
+description: Explore the methodology behind Certificate-based Isolation Policy Design and how it defers from Domain Isolation and Server Isolation Policy Design.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Certificate-based isolation policy design
+
+
+In the certificate-based isolation policy design, you provide the same types of protections to your network traffic as described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) and [Server Isolation Policy Design](server-isolation-policy-design.md) sections. The only difference is the method used to share identification credentials during the authentication of your network traffic.
+
+Domain isolation and server isolation help provide security for the devices on the network that run Windows and that can be joined to an Active Directory domain. However, in most corporate environments there are typically some devices that must run another operating system. These devices can't join an Active Directory domain, without a third-party package being installed. Also, some devices that do run Windows can't join a domain for various reasons. To rely on Kerberos V5 as the authentication protocol, the device needs to be joined to the Active Directory and (for non-Windows devices) support Kerberos as an authentication protocol.
+
+To authenticate with non-domain member devices, IPsec supports using standards-based cryptographic certificates. Because this authentication method is also supported by many third-party operating systems, it can be used as a way to extend your isolated domain to devices that don't run Windows.
+
+The same principles of the domain and server isolation designs apply to this design. Only devices that can authenticate (in this case, by providing a specified certificate) can communicate with the devices in your isolated domain.
+
+For Windows devices that are part of an Active Directory domain, you can use Group Policy to deploy the certificates required to communicate with the devices that are trusted but aren't part of the Active Directory domain. For other devices, you'll have to either manually configure them with the required certificates, or use a third-party program to distribute the certificates in a secure manner.
+
+For more info about this design:
+
+-   This design coincides with the implementation goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
+
+-   To learn more about this design, see [Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md).
+
+-   Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
+
+-   To help you make the decisions required in this design, see [Planning Certificate-based Authentication](planning-certificate-based-authentication.md).
+
+-   For a list of tasks that you can use to deploy your certificate-based policy design, see [Checklist: Implementing a Certificate-based Isolation Policy Design](checklist-implementing-a-certificate-based-isolation-policy-design.md).
+
+

windows/security/operating-system-security/network-security/windows-firewall/change-rules-from-request-to-require-mode.md

@@ -0,0 +1,50 @@
+---
+title: Change Rules from Request to Require Mode 
+description: Learn how to convert a rule from request to require mode and apply the modified GPOs to the client devices.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Change Rules from Request to Require Mode
+
+
+After you confirm that network traffic is being correctly protected by using IPsec, you can change the rules for the domain isolation and encryption zones to require, instead of request, authentication. Don't change the rules for the boundary zone; they must stay in request mode so that devices in the boundary zone can continue to accept connections from devices that aren't part of the isolated domain.
+
+**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.
+
+In this topic:
+
+-   [Convert a rule from request to require mode](#to-convert-a-rule-from-request-to-require-mode)
+
+-   [Apply the modified GPOs to the client devices](#to-apply-the-modified-gpos-to-the-client-devices)
+
+## To convert a rule from request to require mode
+
+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 right navigation pane, click **Connection Security Rules**.
+
+3.  In the details pane, double-click the connection security rule that you want to modify.
+
+4.  Click the **Authentication** tab.
+
+5.  In the **Requirements** section, change **Authenticated mode** to **Require inbound and request outbound**, and then click **OK**.
+
+## To apply the modified GPOs to the client devices
+
+1.  The next time each device refreshes its Group Policy, it will receive the updated GPO and apply the modified rule. To force an immediate refresh, run the following command from an elevated command prompt:
+
+    ``` syntax
+    gpupdate /force
+    ```
+
+2.  To verify that the modified GPO is correctly applied to the client devices, you can run the following command:
+
+    ``` syntax
+    gpresult /r /scope computer
+    ```
+
+3.  Examine the command output for the list of GPOs that are applied to the device, and make sure that the list contains the GPOs you expect to see on that device.

windows/security/operating-system-security/network-security/windows-firewall/checklist-configuring-basic-firewall-settings.md

@@ -0,0 +1,20 @@
+---
+title: Checklist Configuring Basic Firewall Settings 
+description: Configure Windows Firewall to set inbound and outbound behavior, display notifications, record log files and more of the necessary function for Firewall.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Configuring Basic Firewall Settings
+
+
+This checklist includes tasks for configuring a GPO with firewall defaults and settings that are separate from the rules.
+
+**Checklist: Configuring firewall defaults and settings**
+
+| Task | Reference |
+| - | - |
+| Turn the firewall on and set the default inbound and outbound behavior.| [Turn on Windows Defender Firewall with Advanced Security and Configure Default Behavior](turn-on-windows-firewall-and-configure-default-behavior.md)| 
+| Configure the firewall to not display notifications to the user when a program is blocked, and to ignore locally defined firewall and connection security rules. | [Configure Windows Defender Firewall with Advanced Security to Suppress Notifications When a Program Is Blocked](configure-windows-firewall-to-suppress-notifications-when-a-program-is-blocked.md) |
+| Configure the firewall to record a log file. | [Configure the Windows Defender Firewall with Advanced Security Log](configure-the-windows-firewall-log.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-configuring-rules-for-an-isolated-server-zone.md

@@ -0,0 +1,37 @@
+---
+title: Checklist Configuring Rules for an Isolated Server Zone 
+description: Use these tasks to configure connection security rules and IPsec settings in GPOs for servers in an isolated server zone that are part of an isolated domain.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Configuring Rules for an Isolated Server Zone
+
+
+The following checklists include tasks for configuring connection security rules and IPsec settings in your GPOs for servers in an isolated server zone that are part of an isolated domain. For information about creating a standalone isolated server zone that isn't part of an isolated domain, see [Checklist: Implementing a Standalone Server Isolation Policy Design](checklist-implementing-a-standalone-server-isolation-policy-design.md).
+
+In addition to requiring authentication and optionally encryption, servers in an isolated server zone can be accessed only by users or devices who are authenticated members of a network access group (NAG). If you include user accounts in the NAG, then the restrictions can still apply; they're enforced at the application layer, rather than the IP layer.
+
+Devices that are running at least Windows Vista and Windows Server 2008 can identify both devices and users in the NAG because IPsec in these versions of Windows supports AuthIP in addition to IKE. AuthIP adds support for user-based authentication.
+
+The GPOs for an isolated server or group of servers are similar to those GPOs for the isolated domain itself or the encryption zone, if you require encryption to your isolated servers. This checklist refers you to procedures for creating rules and restrictions that allow only members of the NAG to connect to the server.
+
+**Checklist: Configuring rules for isolated servers**
+
+| Task | Reference |
+| - | - |
+| Create a GPO for the devices that need to have access restricted to the same set of client devices. If there are multiple servers and they run different versions of the Windows operating system, then start by creating the GPO for one version of Windows. After you've finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it.<br/>Copy the GPO from the isolated domain or from the encryption zone to serve as a starting point. Where your copy already contains elements listed in the following checklist, review the relevant procedures and compare them to your copied GPO’s element to make sure it's constructed in a way that meets the needs of the server isolation zone. |[Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md)| 
+| Configure the security group filters and WMI filters on the GPO so that only members of the isolated server zone’s membership group that are running the specified version of Windows can read and apply it.| [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Configure IPsec to exempt all ICMP network traffic from IPsec protection. | [Exempt ICMP from Authentication](exempt-icmp-from-authentication.md)| 
+| Configure the key exchange (main mode) security methods and algorithms to be used. | [Configure Key Exchange (Main Mode) Settings](configure-key-exchange-main-mode-settings.md)| 
+| Configure the data protection (quick mode) algorithm combinations to be used. If you require encryption for the isolated server zone, then make sure that you choose only algorithm combinations that include encryption. | [Configure Data Protection (Quick Mode) Settings](configure-data-protection-quick-mode-settings.md)| 
+| Configure the authentication methods to be used. | [Configure Authentication Methods](configure-authentication-methods.md)| 
+| Create a rule that exempts all network traffic to and from devices on the exemption list from IPsec. | [Create an Authentication Exemption List Rule](create-an-authentication-exemption-list-rule.md)| 
+| Create a rule that requests authentication for all network traffic.<br/>**Important:**  As in an isolated domain, don't set the rules to require authentication for inbound traffic until you have completed testing. That way, if the rules don't work as expected, communications aren't affected by a failure to authenticate.| [Create an Authentication Request Rule](create-an-authentication-request-rule.md)| 
+| Create the NAG to contain the device or user accounts that are allowed to access the servers in the isolated server zone. | [Create a Group Account in Active Directory](create-a-group-account-in-active-directory.md)| 
+| Create a firewall rule that permits inbound network traffic only if authenticated as a member of the NAG. | [Restrict Server Access to Members of a Group Only](restrict-server-access-to-members-of-a-group-only.md)| 
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy. | [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add your test server to the membership group for the isolated server zone. Be sure to add at least one server for each operating system supported by a GPO in the group.| [Add Test Devices to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md) |
+
+Don't change the rules for any of your zones to require authentication until all of the zones have been set up and are operating correctly.

windows/security/operating-system-security/network-security/windows-firewall/checklist-configuring-rules-for-servers-in-a-standalone-isolated-server-zone.md

@@ -0,0 +1,34 @@
+---
+title: Checklist Configuring Rules for Servers in a Standalone Isolated Server Zone 
+description: Checklist Configuring Rules for Servers in a Standalone Isolated Server Zone
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone
+
+
+This checklist includes tasks for configuring connection security rules and IPsec settings in your GPOs for servers in a standalone isolated server zone that isn't part of an isolated domain. In addition to requiring authentication and optionally encryption, servers in a server isolation zone are accessible only by users or devices that are authenticated as members of a network access group (NAG). The GPOs described here apply only to the isolated servers, not to the client devices that connect to them. For the GPOs for the client devices, see [Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone](checklist-creating-rules-for-clients-of-a-standalone-isolated-server-zone.md).
+
+The GPOs for isolated servers are similar to those GPOs for an isolated domain. This checklist refers you to those procedures for the creation of some of the rules. The other procedures in this checklist are for creating the restrictions that allow only members of the server access group to connect to the server.
+
+**Checklist: Configuring rules for isolated servers**
+
+| Task | Reference |
+| - | - |
+| Create a GPO for the devices that need to have access restricted to the same set of client devices. If there are multiple servers running different versions of the Windows operating system, start by creating the GPO for one version of Windows. After you've finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it. | [Checklist: Creating Group Policy Objects](checklist-creating-group-policy-objects.md) <br/>[Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md)| 
+| If you're working on a copy of a GPO, modify the group memberships and WMI filters so that they're correct for the devices for which this GPO is intended. | [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Configure IPsec to exempt all ICMP network traffic from IPsec protection. | [Exempt ICMP from Authentication](exempt-icmp-from-authentication.md)| 
+| Create a rule that exempts all network traffic to and from devices on the exemption list from IPsec. | [Create an Authentication Exemption List Rule](create-an-authentication-exemption-list-rule.md) |
+| Configure the key exchange (main mode) security methods and algorithms to be used. | [Configure Key Exchange (Main Mode) Settings](configure-key-exchange-main-mode-settings.md)| 
+| Configure the data protection (quick mode) algorithm combinations to be used. | [Configure Data Protection (Quick Mode) Settings](configure-data-protection-quick-mode-settings.md)| 
+| Configure the authentication methods to be used. This procedure sets the default settings for the device. If you want to set authentication on a per-rule basis, this procedure is optional.| [Configure Authentication Methods](configure-authentication-methods.md) |
+| Create a rule that requests authentication for all inbound network traffic. <br/><br/>**Important:**  As in an isolated domain, don't set the rules to require authentication until your testing is complete. That way, if the rules don't work as expected, communications aren't affected by a failure to authenticate.| [Create an Authentication Request Rule](create-an-authentication-request-rule.md)| 
+| If your design requires encryption in addition to authentication for access to the isolated servers, then modify the rule to require it. | [Configure the Rules to Require Encryption](configure-the-rules-to-require-encryption.md)| 
+| Create the NAG to contain the device or user accounts that are allowed to access the isolated servers. If you have multiple groups of isolated servers that are accessed by different client devices, then create a NAG for each set of servers.| [Create a Group Account in Active Directory](create-a-group-account-in-active-directory.md) |
+| Create a firewall rule that allows inbound network traffic only if it's authenticated from a user or device that is a member of the zone’s NAG.| [Restrict Server Access to Members of a Group Only](restrict-server-access-to-members-of-a-group-only.md)| 
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy. | [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add your test server to the membership group for the isolated server zone. Be sure to add at least one for each operating system supported by a different GPO in the group.| [Add Test Devices to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md)| 
+ 
+Don't change the rules for any of your zones to require authentication until all zones have been set up and thoroughly tested.

windows/security/operating-system-security/network-security/windows-firewall/checklist-configuring-rules-for-the-boundary-zone.md

@@ -0,0 +1,26 @@
+---
+title: Checklist Configuring Rules for the Boundary Zone 
+description: Use these tasks to configure connection security rules and IPsec settings in your GPOs to implement the boundary zone in an isolated domain.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Configuring Rules for the Boundary Zone
+
+
+The following checklists include tasks for configuring connection security rules and IPsec settings in your GPOs to implement the boundary zone in an isolated domain.
+
+Rules for the boundary zone are typically the same as those rules for the isolated domain, with the exception that the final rule is left to only request, not require, authentication.
+
+**Checklist: Configuring boundary zone rules**
+
+This checklist assumes that you've already created the GPO for the isolated domain as described in [Checklist: Implementing a Domain Isolation Policy Design](checklist-implementing-a-domain-isolation-policy-design.md). After you create a copy for the boundary zone, make sure that you don't change the rule from request authentication to require authentication when you create the other GPOs.
+
+| Task | Reference |
+| - | - |
+| Make a copy of the domain isolation GPO for this version of Windows to serve as a starting point for the GPO for the boundary zone. Unlike the GPO for the main isolated domain zone, this copy isn't changed after deployment to require authentication.| [Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md) |
+| If you're working on a copy of a GPO, modify the group memberships and WMI filters so that they're correct for the boundary zone and version of Windows for which this GPO is intended.| [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy.| [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add your test computers to the membership group for the boundary zone. Be sure to add at least one for each operating system supported by a different GPO in the group.| [Add Test Computers to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md)| 
+| Verify that the connection security configuration is protecting network traffic with authentication when it can, and that unauthenticated traffic is accepted. | [Verify That Network Traffic Is Authenticated](verify-that-network-traffic-is-authenticated.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-configuring-rules-for-the-encryption-zone.md

@@ -0,0 +1,27 @@
+---
+title: Checklist Configuring Rules for the Encryption Zone 
+description: Use these tasks to configure connection security rules and IPsec settings in your GPOs to implement the encryption zone in an isolated domain.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Configuring Rules for the Encryption Zone
+
+
+This checklist includes tasks for configuring connection security rules and IPsec settings in your GPOs to implement the encryption zone in an isolated domain.
+
+Rules for the encryption zone are typically the same as those rules for the isolated domain, with the exception that the main rule requires encryption in addition to authentication.
+
+**Checklist: Configuring encryption zone rules**
+
+This checklist assumes that you've already created the GPO for the isolated domain as described in [Checklist: Implementing a Domain Isolation Policy Design](checklist-implementing-a-domain-isolation-policy-design.md). You can then copy those GPOs for use with the encryption zone. After you create the copies, modify the main rule to require encryption in addition to the authentication required by the rest of the isolated domain.
+
+| Task | Reference |
+| - | - |
+| Make a copy of the domain isolation GPOs to serve as a starting point for the GPOs for the encryption zone.| [Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md)| 
+| Modify the group memberships and WMI filters so that they're correct for the encryption zone and the version of Windows for which this GPO is intended. | [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Add the encryption requirements for the zone. | [Configure the Rules to Require Encryption](configure-the-rules-to-require-encryption.md)| 
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy. | [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add your test computers to the membership group for the encryption zone. Be sure to add at least one for each operating system supported by a different GPO in the group.| [Add Test Computers to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md)| 
+| Verify that the connection security rules are protecting network traffic.| [Verify That Network Traffic Is Authenticated](verify-that-network-traffic-is-authenticated.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-configuring-rules-for-the-isolated-domain.md

@@ -0,0 +1,31 @@
+---
+title: Checklist Configuring Rules for the Isolated Domain 
+description: Use these tasks to configure connection security rules and IPsec settings in your GPOs to implement the main zone in the isolated domain.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Configuring Rules for the Isolated Domain
+
+
+The following checklists include tasks for configuring connection security rules and IPsec settings in your GPOs to implement the main zone in the isolated domain.
+
+**Checklist: Configuring isolated domain rules**
+
+| Task | Reference |
+| - | - |
+| Create a GPO for the computers in the isolated domain running one of the operating systems. After you've finished the tasks in this checklist and configured the GPO for that version of Windows, you can create a copy of it.| [Checklist: Creating Group Policy Objects](checklist-creating-group-policy-objects.md)<br/>[Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md)| 
+| If you're working on a GPO that was copied from another GPO, modify the group memberships and WMI filters so that they're correct for the isolated domain zone and the version of Windows for which this GPO is intended. | [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Configure IPsec to exempt all ICMP network traffic from IPsec protection. | [Exempt ICMP from Authentication](exempt-icmp-from-authentication.md)| 
+| Create a rule that exempts all network traffic to and from computers on the exemption list from IPsec. | [Create an Authentication Exemption List Rule](create-an-authentication-exemption-list-rule.md)| 
+| Configure the key exchange (main mode) security methods and algorithms to be used. | [Configure Key Exchange (Main Mode) Settings](configure-key-exchange-main-mode-settings.md)| 
+| Configure the data protection (quick mode) algorithm combinations to be used. | [Configure Data Protection (Quick Mode) Settings](configure-data-protection-quick-mode-settings.md)| 
+| Configure the authentication methods to be used. | [Configure Authentication Methods](configure-authentication-methods.md)| 
+| Create the rule that requests authentication for all inbound network traffic. | [Create an Authentication Request Rule](create-an-authentication-request-rule.md)| 
+| Link the GPO to the domain level of the AD DS organizational unit hierarchy. | [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add your test computers to the membership group for the isolated domain. Be sure to add at least one for each operating system supported by a different GPO in the group.| [Add Test Devices to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md)| 
+| Verify that the connection security rules are protecting network traffic to and from the test computers. | [Verify That Network Traffic Is Authenticated](verify-that-network-traffic-is-authenticated.md)| 
+ 
+
+Don't change the rules for any of your zones to require authentication until all of the zones have been set up and are operating correctly.

windows/security/operating-system-security/network-security/windows-firewall/checklist-creating-group-policy-objects.md

@@ -0,0 +1,37 @@
+---
+title: Checklist Creating Group Policy Objects 
+description: Learn to deploy firewall settings, IPsec settings, firewall rules, or connection security rules, by using Group Policy in AD DS.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Creating Group Policy Objects
+
+
+To deploy firewall or IPsec settings or firewall or connection security rules, we recommend that you use Group Policy in AD DS. This section describes a tested, efficient method that requires some up-front work, but serves an administrator well in the end by making GPO assignments as easy as dropping a device into a membership group.
+
+The checklists for firewall, domain isolation, and server isolation include a link to this checklist.
+
+## About membership groups
+
+For most GPO deployment tasks, you must determine which devices must receive and apply which GPOs. Because different versions of Windows can support different settings and rules to achieve similar behavior, you might need multiple GPOs: one for each operating system that has settings different from the others to achieve the same result. For example, Windows 11, Windows 10, Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 use rules and settings that are incompatible with Windows 2000, Windows XP, and Windows Server 2003. Therefore, if your network included those older operating systems you would need to create a GPO for each set of operating systems that can share common settings. To deploy typical domain isolation settings and rules, you might have five different GPOs for the versions of Windows discussed in this guide. By following the procedures in this guide, you only need one membership group to manage all five GPOs. The membership group is identified in the security group filter for all five GPOs. To apply the settings to a device, you make that device's account a member of the membership group. WMI filters are used to ensure that the correct GPO is applied.
+
+## About exclusion groups
+
+A Windows Defender Firewall with Advanced Security design must often take into account domain-joined devices on the network that can't or must not apply the rules and settings in the GPOs. Because these devices are typically fewer in number than the devices that must apply the GPO, it's easier to use the Domain Members group in the GPO membership group, and then place these exception devices into an exclusion group that is denied Apply Group Policy permissions on the GPO. Because deny permissions take precedence over allow permissions, a device that is a member of both the membership group and the exception group is prevented from applying the GPO. Devices typically found in a GPO exclusion group for domain isolation include the domain controllers, DHCP servers, and DNS servers.
+
+You can also use a membership group for one zone as an exclusion group for another zone. For example, devices in the boundary and encryption zones are technically in the main domain isolation zone, but must apply only the GPO for their assigned role. To use the group as an exclusion group, the GPOs for the main isolation zone deny Apply Group Policy permissions to members of the boundary and encryption zones.
+
+**Checklist: Creating Group Policy objects**
+
+| Task | Reference |
+| - | - |
+| Review important concepts and examples for deploying GPOs in a way that best meets the needs of your organization.| [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)<br/>[Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md)| 
+| Create the membership group in AD DS that will be used to contain device accounts that must receive the GPO.<br/>If some devices in the membership group are running an operating system that doesn't support WMI filters, such as Windows 2000, create an exclusion group to contain the device accounts for the devices that can't be blocked by using a WMI filter.| [Create a Group Account in Active Directory](create-a-group-account-in-active-directory.md)|
+| Create a GPO for each version of Windows that has different implementation requirements.| [Create a Group Policy Object](create-a-group-policy-object.md) |
+| Create security group filters to limit the GPO to only devices that are members of the membership group and to exclude devices that are members of the exclusion group.|[Assign Security Group Filters to the GPO](assign-security-group-filters-to-the-gpo.md) |
+| Create WMI filters to limit each GPO to only the devices that match the criteria in the filter.| [Create WMI Filters for the GPO](create-wmi-filters-for-the-gpo.md) |
+| If you're working on a GPO that was copied from another, modify the group memberships and WMI filters so that they're correct for the new zone or version of Windows for which this GPO is intended.|[Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy.| [Link the GPO to the Domain](link-the-gpo-to-the-domain.md) |
+| Before adding any rules or configuring the GPO, add a few test devices to the membership group, and make sure that the correct GPO is received and applied to each member of the group.| [Add Test Devices to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md) |

windows/security/operating-system-security/network-security/windows-firewall/checklist-creating-inbound-firewall-rules.md

@@ -0,0 +1,33 @@
+---
+title: Checklist Creating Inbound Firewall Rules 
+description: Use these tasks for creating inbound firewall rules in your GPOs for Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Creating Inbound Firewall Rules
+
+
+This checklist includes tasks for creating firewall rules in your GPOs.
+
+**Checklist: Creating inbound firewall rules**
+
+| Task | Reference |
+| - | - |
+| Create a rule that allows a program to listen for and accept inbound network traffic on any ports it requires. | [Create an Inbound Program or Service Rule](create-an-inbound-program-or-service-rule.md)| 
+| Create a rule that allows inbound network traffic on a specified port number. | [Create an Inbound Port Rule](create-an-inbound-port-rule.md)| 
+| Create a rule that allows inbound ICMP network traffic. | [Create an Inbound ICMP Rule](create-an-inbound-icmp-rule.md)| 
+| Create rules that allow inbound RPC network traffic. | [Create Inbound Rules to Support RPC](create-inbound-rules-to-support-rpc.md)| 
+| Enable a predefined rule or a group of predefined rules. Some predefined rules for basic network services are included as part of the installation of Windows; others can be created when you install a new application or network service. | [Enable Predefined Inbound Rules](enable-predefined-inbound-rules.md)| 
+
+ 
+
+ 
+
+ 
+
+
+
+
+

windows/security/operating-system-security/network-security/windows-firewall/checklist-creating-outbound-firewall-rules.md

@@ -0,0 +1,33 @@
+---
+title: Checklist Creating Outbound Firewall Rules 
+description: Use these tasks for creating outbound firewall rules in your GPOs for Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Creating Outbound Firewall Rules
+
+
+This checklist includes tasks for creating outbound firewall rules in your GPOs.
+
+>**Important:**  By default, outbound filtering is disabled. Because all outbound network traffic is permitted, outbound rules are typically used to block traffic that is not wanted on the network. However, it is a best practice for an administrator to create outbound allow rules for those applications that are approved for use on the organization’s network. If you do this, then you have the option to set the default outbound behavior to block, preventing any network traffic that is not specifically authorized by the rules you create.
+
+**Checklist: Creating outbound firewall rules for Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, or Windows Server 2008 R2**
+
+| Task | Reference |
+| - | - |
+| Create a rule that allows a program to send any outbound network traffic on any port it requires. | [Create an Outbound Program or Service Rule](create-an-outbound-program-or-service-rule.md)| 
+| Create a rule that allows outbound network traffic on a specified port number. | [Create an Outbound Port Rule](create-an-outbound-port-rule.md)| 
+| Enable a predefined rule or a group of predefined rules. Some predefined rules for basic network services are included as part of the installation of Windows; others can be created when you install a new application or network service. | [Enable Predefined Outbound Rules](enable-predefined-outbound-rules.md)| 
+
+ 
+
+ 
+
+ 
+
+
+
+
+

windows/security/operating-system-security/network-security/windows-firewall/checklist-creating-rules-for-clients-of-a-standalone-isolated-server-zone.md

@@ -0,0 +1,27 @@
+---
+title: Create Rules for Standalone Isolated Server Zone Clients 
+description: Checklist for when creating rules for clients of a Standalone Isolated Server Zone
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone
+
+
+This checklist includes tasks for configuring connection security rules and IPsec settings in the GPOs for client devices that must connect to servers in an isolated server zone.
+
+**Checklist: Configuring isolated server zone client rules**
+
+| Task | Reference |
+| - | - |
+| Create a GPO for the client devices that must connect to servers in the isolated server zone, and that are running one of the versions of Windows. After you've finished the tasks in this checklist, you can make a copy of it.| [Checklist: Creating Group Policy Objects](checklist-creating-group-policy-objects.md) <br/>[Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md)| 
+| To determine which devices receive the GPO, assign the NAG for the isolated servers to the security group filter for the GPO. Make sure that each GPO has the WMI filter for the correct version of Windows.| [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md) |
+| Configure IPsec to exempt all ICMP network traffic from IPsec protection. | [Exempt ICMP from Authentication](exempt-icmp-from-authentication.md)| 
+| Create a rule that exempts all network traffic to and from devices on the exemption list from IPsec. | [Create an Authentication Exemption List Rule](create-an-authentication-exemption-list-rule.md)| 
+| Configure the key exchange (main mode) security methods and algorithms to be used. | [Configure Key Exchange (Main Mode) Settings](configure-key-exchange-main-mode-settings.md)| 
+| Configure the data protection (quick mode) algorithm combinations to be used. | [Configure Data Protection (Quick Mode) Settings](configure-data-protection-quick-mode-settings.md)| 
+| Configure the authentication methods to be used. | [Configure Authentication Methods](configure-authentication-methods.md)| 
+| Create a rule that requests authentication for network traffic. Because fallback-to-clear behavior in Windows Vista and Windows Server 2008 has no delay when communicating with devices that can't use IPsec, you can use the same any-to-any rule used in an isolated domain.| [Create an Authentication Request Rule](create-an-authentication-request-rule.md)| 
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy. | [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add your test devices to the NAG for the isolated server zone. Be sure to add at least one for each operating system supported by a different GPO in the group.| [Add Test Devices to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-implementing-a-basic-firewall-policy-design.md

@@ -0,0 +1,30 @@
+---
+title: Checklist Implementing a Basic Firewall Policy Design 
+description: Follow this parent checklist for implementing a basic firewall policy design to ensure successful implementation.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Implementing a Basic Firewall Policy Design
+
+
+This parent checklist includes cross-reference links to important concepts about the basic firewall policy design. It also contains links to subordinate checklists that will help you complete the tasks that are required to implement this design.
+
+>**Note:**  Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist.
+
+The procedures in this section use the Group Policy MMC snap-in interfaces to configure the GPOs, but you can also use Windows PowerShell. For more info, see [Windows Defender Firewall with Advanced Security Administration with Windows PowerShell](windows-firewall-with-advanced-security-administration-with-windows-powershell.md).
+
+ **Checklist: Implementing a basic firewall policy design**
+
+| Task | Reference |
+| - | - |
+| Review important concepts and examples for the basic firewall policy design to determine if this design meets the needs of your organization. | [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)<br/>[Basic Firewall Policy Design](basic-firewall-policy-design.md)<br/>[Firewall Policy Design Example](firewall-policy-design-example.md)<br/>[Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md)| 
+| Create the membership group and a GPO for each set of devices that require different firewall rules. Where GPOs will be similar, such as for Windows 11, Windows 10, and Windows Server 2016, create one GPO, configure it by using the tasks in this checklist, and then make a copy of the GPO for the other version of Windows. For example, create and configure the GPO for Windows 10 or Windows 11, make a copy of it for Windows Server 2016, and then follow the steps in this checklist to make the few required changes to the copy. | [Checklist: Creating Group Policy Objects](checklist-creating-group-policy-objects.md)<br/>[Copy a GPO to Create a New GPO](copy-a-gpo-to-create-a-new-gpo.md)| 
+| If you are working on a GPO that was copied from another, modify the group membership and WMI filters so that they are correct for the devices for which this GPO is intended.| [Modify GPO Filters to Apply to a Different Zone or Version of Windows](modify-gpo-filters-to-apply-to-a-different-zone-or-version-of-windows.md)| 
+| Configure the GPO with firewall default settings appropriate for your design.| [Checklist: Configuring Basic Firewall Settings](checklist-configuring-basic-firewall-settings.md)| 
+| Create one or more inbound firewall rules to allow unsolicited inbound network traffic.| [Checklist: Creating Inbound Firewall Rules](checklist-creating-inbound-firewall-rules.md)| 
+| Create one or more outbound firewall rules to block unwanted outbound network traffic. | [Checklist: Creating Outbound Firewall Rules](checklist-creating-outbound-firewall-rules.md)| 
+| Link the GPO to the domain level of the Active Directory organizational unit hierarchy.| [Link the GPO to the Domain](link-the-gpo-to-the-domain.md)| 
+| Add test devices to the membership group, and then confirm that the devices receive the firewall rules from the GPOs as expected.| [Add Test Devices to the Membership Group for a Zone](add-test-devices-to-the-membership-group-for-a-zone.md)|
+| According to the testing and roll-out schedule in your design plan, add device accounts to the membership group to deploy the completed firewall policy settings to your devices. | [Add Production Devices to the Membership Group for a Zone](add-production-devices-to-the-membership-group-for-a-zone.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-implementing-a-certificate-based-isolation-policy-design.md

@@ -0,0 +1,25 @@
+---
+title: Checklist Implementing a Certificate-based Isolation Policy Design 
+description: Use these references to learn about using certificates as an authentication option and configure a certificate-based isolation policy design.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Implementing a Certificate-based Isolation Policy Design
+
+
+This parent checklist includes cross-reference links to important concepts about using certificates as an authentication option in either a domain isolation or server isolation design.
+
+> [!NOTE]
+> Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist
+
+**Checklist: Implementing certificate-based authentication**
+
+| Task | Reference |
+| - | - |
+| Review important concepts and examples for certificate-based authentication to determine if this design meets your implementation goals and the needs of your organization.| [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)<br/>[Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md)<br/>[Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md)<br/>[Planning Certificate-based Authentication](planning-certificate-based-authentication.md) |
+| Install the Active Directory Certificate Services (AD CS) role as an enterprise root issuing certification authority (CA). This step is required only if you haven't already deployed a CA on your network.| |
+| Configure the certificate template for workstation authentication certificates.| [Configure the Workstation Authentication Certificate Template](configure-the-workstation-authentication-certificate-template.md)| 
+| Configure Group Policy to automatically deploy certificates based on your template to workstation devices. | [Configure Group Policy to Autoenroll and Deploy Certificates](configure-group-policy-to-autoenroll-and-deploy-certificates.md)| 
+| On a test device, refresh Group Policy and confirm that the certificate is installed. | [Confirm That Certificates Are Deployed Correctly](confirm-that-certificates-are-deployed-correctly.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-implementing-a-domain-isolation-policy-design.md

@@ -0,0 +1,29 @@
+---
+title: Checklist Implementing a Domain Isolation Policy Design 
+description: Use these references to learn about the domain isolation policy design and links to other checklists to complete tasks require to implement this design.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Implementing a Domain Isolation Policy Design
+
+
+This parent checklist includes cross-reference links to important concepts about the domain isolation policy design. It also contains links to subordinate checklists that will help you complete the tasks that are required to implement this design.
+
+> [!NOTE]
+> Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist.
+
+The procedures in this section use the Group Policy MMC snap-ins to configure the GPOs, but you can also use Windows PowerShell to configure GPOs. For more info, see [Windows Defender Firewall with Advanced Security Administration with Windows PowerShell](windows-firewall-with-advanced-security-administration-with-windows-powershell.md).
+
+**Checklist: Implementing a domain isolation policy design**
+
+| Task | Reference |
+| - | - |
+| Review important concepts and examples for the domain isolation policy design, determine your Windows Defender Firewall with Advanced Security implementation goals, and customize this design to meet the needs of your organization.| [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)<br/>[Domain Isolation Policy Design](domain-isolation-policy-design.md)<br/>[Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md)<br/>[Planning Domain Isolation Zones](planning-domain-isolation-zones.md) |
+| Create the GPOs and connection security rules for the isolated domain.| [Checklist: Configuring Rules for the Isolated Domain](checklist-configuring-rules-for-the-isolated-domain.md)| 
+| Create the GPOs and connection security rules for the boundary zone.| [Checklist: Configuring Rules for the Boundary Zone](checklist-configuring-rules-for-the-boundary-zone.md)| 
+| Create the GPOs and connection security rules for the encryption zone.| [Checklist: Configuring Rules for the Encryption Zone](checklist-configuring-rules-for-the-encryption-zone.md)| 
+| Create the GPOs and connection security rules for the isolated server zone.| [Checklist: Configuring Rules for an Isolated Server Zone](checklist-configuring-rules-for-an-isolated-server-zone.md)| 
+| According to the testing and roll-out schedule in your design plan, add computer accounts to the membership group to deploy rules and settings to your computers.| [Add Production Devices to the Membership Group for a Zone](add-production-devices-to-the-membership-group-for-a-zone.md)| 
+| After you confirm that network traffic is authenticated by IPsec, you can change authentication rules for the isolated domain and encryption zone from request to require mode.| [Change Rules from Request to Require Mode](change-rules-from-request-to-require-mode.md)| 

windows/security/operating-system-security/network-security/windows-firewall/checklist-implementing-a-standalone-server-isolation-policy-design.md

@@ -0,0 +1,28 @@
+---
+title: Checklist Implementing a Standalone Server Isolation Policy Design 
+description: Use these tasks to create a server isolation policy design that isn't part of an isolated domain. See references to concepts and links to other checklists.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Checklist: Implementing a Standalone Server Isolation Policy Design
+
+
+This checklist contains procedures for creating a server isolation policy design that isn't part of an isolated domain. For information on the steps required to create an isolated server zone within an isolated domain, see [Checklist: Configuring Rules for an Isolated Server Zone](checklist-configuring-rules-for-an-isolated-server-zone.md).
+
+This parent checklist includes cross-reference links to important concepts about the domain isolation policy design. It also contains links to subordinate checklists that will help you complete the tasks that are required to implement this design.
+
+> [!NOTE]
+> Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist.
+
+**Checklist: Implementing a standalone server isolation policy design**
+
+| Task | Reference |
+| - | - |
+| Review important concepts and examples for the server isolation policy design to determine if this design meets your implementation goals and the needs of your organization.| [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)<br/>[Server Isolation Policy Design](server-isolation-policy-design.md)<br/>[Server Isolation Policy Design Example](server-isolation-policy-design-example.md)<br/>[Planning Server Isolation Zones](planning-server-isolation-zones.md) |
+| Create the GPOs and connection security rules for isolated servers.| [Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone](checklist-configuring-rules-for-servers-in-a-standalone-isolated-server-zone.md)| 
+| Create the GPOs and connection security rules for the client devices that must connect to the isolated servers. | [Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone](checklist-creating-rules-for-clients-of-a-standalone-isolated-server-zone.md)| 
+| Verify that the connection security rules are protecting network traffic on your test devices. | [Verify That Network Traffic Is Authenticated](verify-that-network-traffic-is-authenticated.md)| 
+| After you confirm that network traffic is authenticated by IPsec as expected, you can change authentication rules for the isolated server zone to require authentication instead of requesting it. | [Change Rules from Request to Require Mode](change-rules-from-request-to-require-mode.md)| 
+| According to the testing and roll-out schedule in your design plan, add device accounts for the client devices to the membership group so that you can deploy the settings. | [Add Production Devices to the Membership Group for a Zone](add-production-devices-to-the-membership-group-for-a-zone.md) |

windows/security/operating-system-security/network-security/windows-firewall/configure-authentication-methods.md

@@ -0,0 +1,58 @@
+---
+title: Configure Authentication Methods 
+description: Learn how to configure authentication methods for devices in an isolated domain or standalone server zone in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Configure Authentication Methods
+
+
+This procedure shows you how to configure the authentication methods that can be used by computers in an isolated domain or standalone isolated server zone.
+
+>**Note:**  If you follow the steps in the procedure in this topic, you alter the system-wide default settings. Any connection security rule can use these settings by specifying **Default** on the **Authentication** tab.
+
+**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 authentication methods**
+
+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 on the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
+
+3. On the **IPsec Settings** tab, click **Customize**.
+
+4. In the **Authentication Method** section, select the type of authentication that you want to use from among the following:
+
+   1.  **Default**. Selecting this option tells the computer to use the authentication method currently defined by the local administrator in Windows Defender Firewall or by Group Policy as the default.
+
+   2.  **Computer certificate from this certification authority**. Selecting this option and entering the identification of a certification authority (CA) tells the computer to use and require authentication by using a certificate that is issued by the selected CA. If you also select **Accept only health certificates**, then only certificates that include the system health authentication extended key usage (EKU) typically provided in a Network Access Protection (NAP) infrastructure can be used for this rule.
+
+   3.  **Advanced**. Click **Customize** to specify a custom combination of authentication methods required for your scenario. You can specify both a **First authentication method** and a **Second authentication method**.
+
+       The first authentication method can be one of the following methods:
+
+       -   **Computer (NTLMv2)**. Selecting this option tells the computer to use and require authentication of the computer by using its domain credentials. This option works only with other computers that can use AuthIP. User-based authentication using Kerberos V5 isn't supported by IKE v1.
+
+       -   **Computer certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by that CA. If you also select **Accept only health certificates**, then only certificates issued by a NAP server can be used.
+
+       -   **Preshared key (not recommended)**. Selecting this method and entering a preshared key tells the computer to authenticate by exchanging the preshared keys. If they match, then the authentication succeeds. This method isn't recommended, and is included only for backward compatibility and testing purposes.
+
+       If you select **First authentication is optional**, then the connection can succeed even if the authentication attempt specified in this column fails.
+
+       The second authentication method can be one of the following methods:
+
+       -   **User (NTLMv2)**. Selecting this option tells the computer to use and require authentication of the currently signed-in user by using their domain credentials, and uses the NTLMv2 protocol instead of Kerberos V5. This authentication method works only with other computers that can use AuthIP. User-based authentication using Kerberos V5 isn't supported by IKE v1.
+
+       -   **User health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the computer to use and require user-based authentication by using a certificate that is issued by the specified CA. If you also select **Enable certificate to account mapping**, then the certificate can be associated with a user in Active Directory for purposes of granting or denying access to specified users or user groups.
+
+       -   **Computer health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the computer to use and require authentication by using a certificate that is issued by the specified CA. If you also select **Accept only health certificates**, then only certificates that include the system health authentication EKU typically provided in a NAP infrastructure can be used for this rule.
+
+       If you select **Second authentication is optional**, then the connection can succeed even if the authentication attempt specified in this column fails.
+
+       >**Important:**  Make sure that you do not select the check boxes to make both first and second authentication optional. Doing so allows plaintext connections whenever authentication fails.
+
+5. Click **OK** on each dialog box to save your changes and return to the Group Policy Management Editor.

windows/security/operating-system-security/network-security/windows-firewall/configure-data-protection-quick-mode-settings.md

@@ -0,0 +1,56 @@
+---
+title: Configure Data Protection (Quick Mode) Settings 
+description: Learn how to configure the data protection settings for connection security rules in an isolated domain or a standalone isolated server zone.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Configure Data Protection (Quick Mode) Settings
+
+
+This procedure shows you how to configure the data protection (quick mode) settings for connection security rules in an isolated domain or a standalone isolated server zone.
+
+**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 quick mode settings**
+
+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 on the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
+
+3.  On the **IPsec Settings** tab, click **Customize**.
+
+4.  In the **Data protection (Quick Mode)** section, click **Advanced**, and then click **Customize**.
+
+5.  If you require encryption for all network traffic in the specified zone, then check **Require encryption for all connection security rules that use these settings**. Selecting this option disables the **Data integrity** section, and forces you to select only integrity algorithms that are combined with an encryption algorithm. If you do not select this option, then you can use only data integrity algorithms. Before selecting this option, consider the performance impact and the increase in network traffic that will result. We recommend that you use this setting only on network traffic that truly requires it, such as to and from computers in the encryption zone.
+
+6.  If you did not select **Require encryption**, then select the data integrity algorithms that you want to use to help protect the data sessions between the two computers. If the data integrity algorithms displayed in the list are not what you want, then do the following:
+
+    1.  From the left column, remove any of the data integrity algorithms that you do not want by selecting the algorithm and then clicking **Remove**.
+
+    2.  Add any required data integrity algorithms by clicking **Add**, selecting the appropriate protocol (ESP or AH) and algorithm (SHA1 or MD5), selecting the key lifetime in minutes or sessions, and then clicking **OK**. We recommend that you do not include MD5 in any combination. It is included for backward compatibility only. We also recommend that you use ESP instead of AH if you have any devices on your network that use network address translation (NAT).
+
+    3.  In **Key lifetime (in sessions)**, type the number of times that the quick mode session can be rekeyed. After this number is reached, the quick mode SA must be renegotiated. Be careful to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance because of the more frequent renegotiating of the quick mode SA. We recommend that you use the default value unless your risk analysis indicates the need for a different value.
+
+    4.  Click **OK** to save your algorithm combination settings.
+
+    5.  After the list contains only the combinations you want, use the up and down arrows to the right of the list to rearrange them in the correct order for your design. The algorithm combination that is first in the list is tried first, and so on.
+
+7.  Select the data integrity and encryption algorithms that you want to use to help protect the data sessions between the two computers. If the algorithm combinations displayed in the list are not what you want, then do the following:
+
+    1.  From the second column, remove any of the data integrity and encryption algorithms that you do not want by selecting the algorithm combination and then clicking **Remove**.
+
+    2.  Add any required integrity and encryption algorithm combinations by clicking **Add**, and then doing the following:
+
+    3.  Select the appropriate protocol (ESP or AH). We recommend that you use ESP instead of AH if you have any devices on your network that use NAT.
+
+    4.  Select the appropriate encryption algorithm. The choices include, in order of decreasing security: AES-256, AES-192, AES-128, 3DES, and DES. We recommend that you do not include DES in any combination. It is included for backward compatibility only.
+
+    5.  Select the appropriate integrity algorithm (SHA1 or MD5). We recommend that you do not include MD5 in any combination. It is included for backward compatibility only.
+
+    6.  In **Key lifetime (in minutes)**, type the number of minutes. When the specified number of minutes has elapsed, any IPsec operations between the two computers that negotiated this key will require a new key. Be careful to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance because of the more frequent rekeying. We recommend that you use the default value unless your risk analysis indicates the need for a different value.
+
+8.  Click **OK** three times to save your settings.

windows/security/operating-system-security/network-security/windows-firewall/configure-group-policy-to-autoenroll-and-deploy-certificates.md

@@ -0,0 +1,32 @@
+---
+title: Configure Group Policy to Autoenroll and Deploy Certificates 
+description: Learn how to configure Group Policy to automatically enroll client computer certificates and deploy them to the workstations on your network.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Configure Group Policy to Autoenroll and Deploy Certificates
+
+
+You can use this procedure to configure Group Policy to automatically enroll client computer certificates and deploy them to the workstations on your network. Follow this procedure for each GPO that contains IPsec connection security rules that require this certificate.
+
+**Administrative credentials**
+
+To complete these procedures, you must be a member of both the Domain Admins group in the root domain of your forest and a member of the Enterprise Admins group.
+
+**To configure Group Policy to autoenroll certificates**
+
+1.  Open the Group Policy Management console.
+
+2.  In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, expand **Group Policy Objects**, right-click the GPO you want to modify, and then click **Edit**.
+
+3.  In the navigation pane, expand the following path: **Computer Configuration**, **Policies**, **Windows Settings**, **Security Settings**, **Public Key Policies**.
+
+4.  Double-click **Certificate Services Client - Auto-Enrollment**.
+
+5.  In the **Properties** dialog box, change **Configuration Model** to **Enabled**.
+
+6.  Select both **Renew expired certificates, update pending certificates, and remove revoked certificates** and **Update certificates that use certificate templates**.
+
+7.  Click **OK** to save your changes. Computers apply the GPO and download the certificate the next time Group Policy is refreshed.

windows/security/operating-system-security/network-security/windows-firewall/configure-key-exchange-main-mode-settings.md

@@ -0,0 +1,56 @@
+---
+title: Configure Key Exchange (Main Mode) Settings 
+description: Learn how to configure the main mode key exchange settings used to secure the IPsec authentication traffic in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Configure Key Exchange (Main Mode) Settings
+
+
+This procedure shows you how to configure the main mode key exchange settings used to secure the IPsec authentication traffic.
+
+**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 key exchange settings**
+
+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 on the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
+
+3.  On the **IPsec Settings** tab, click **Customize**.
+
+4.  In the **Key exchange (Main Mode)** section, click **Advanced**, and then click **Customize**.
+
+5.  Select the security methods to be used to help protect the main mode negotiations between the two devices. If the security methods displayed in the list aren't what you want, then do the following steps:
+
+    **Important**  
+    In Windows Vista, Windows Server 2008, or later, you can specify only one key exchange algorithm. This rule means that if you want to communicate by using IPsec with another device running Windows 8 or Windows Server 2012, then you must select the same key exchange algorithm on both devices.
+
+    Also, if you create a connection security rule that specifies an option that requires AuthIP instead of IKE, then only the one combination of the top integrity and encryption security method is used in the negotiation. Ensure that all of your devices that are running at least Windows Vista and Windows Server 2008 have the same methods at the top of the list and the same key exchange algorithm selected.
+
+    **Note**  
+    When AuthIP is used, no Diffie-Hellman key exchange protocol is used. Instead, when Kerberos V5 authentication is requested, the Kerberos V5 service ticket secret is used in place of a Diffie-Hellman value. When either certificate authentication or NTLM authentication is requested, a transport level security (TLS) session is established, and its secret is used in place of the Diffie-Hellman value. This event happens no matter which Diffie-Hellman key exchange protocol you select.
+
+    1.  Remove any of the security methods that you don't want by selecting the method and then clicking **Remove**.
+
+    2.  Add any required security method combinations by clicking **Add**, selecting the appropriate encryption algorithm and integrity algorithm from the lists, and then clicking **OK**.
+
+        >**Caution:**  We recommend that you do not include MD5 or DES in any combination. They are included for backward compatibility only.
+
+    3.  After the list contains only the combinations you want, use the "up" and "down" arrows to the right of the list to arrange them in the order of preference. The combination that appears first in the list is tried first, and so on.
+
+6.  From the list on the right, select the key exchange algorithm that you want to use.
+
+    >**Caution:**  We recommend that you do not use Diffie-Hellman Group 1. It is included for backward compatibility only. 
+
+7.  In **Key lifetime (in minutes)**, type the number of minutes. When the specified number of minutes has elapsed, any IPsec operation between the two devices requires a new key.
+
+    >**Note:**  You need to balance performance with security requirements. Although a shorter key lifetime results in better security, it also reduces performance.
+
+8.  In **Key lifetime (in sessions)**, type the number of sessions. After the specified number of quick mode sessions have been created within the security association protected by this key, IPsec requires a new key.
+
+9.  Click **OK** three times to save your settings.

windows/security/operating-system-security/network-security/windows-firewall/configure-the-rules-to-require-encryption.md

@@ -0,0 +1,50 @@
+---
+title: Configure the Rules to Require Encryption 
+description: Learn how to configure rules to add encryption algorithms and delete the algorithm combinations that don't use encryption for zones that require encryption.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Configure the Rules to Require Encryption
+
+If you're creating a zone that requires encryption, you must configure the rules to add the encryption algorithms and delete the algorithm combinations that don't use encryption.
+
+**Administrative credentials**
+
+To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
+
+**To modify an authentication request rule to also require encryption**
+
+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 navigation pane, click **Connection Security Rules**.
+
+3. In the details pane, double-click the connection security rule you want to modify.
+
+4. On the **Name** page, rename the connection security rule, edit the description to reflect the new use for the rule, and then click **OK**.
+
+5. In the navigation pane, right-click **Windows Defender Firewall – LDAP://CN={**<em>guid</em>**}**, and then click **Properties**.
+
+6. Click the **IPsec Settings** tab.
+
+7. Under **IPsec defaults**, click **Customize**.
+
+8. Under **Data protection (Quick Mode)**, click **Advanced**, and then click **Customize**.
+
+9. Click **Require encryption for all connection security rules that use these settings**.
+
+   This setting disables the data integrity rules section. Ensure the **Data integrity and encryption** list contains all of the combinations that your client devices will use to connect to members of the encryption zone. The client devices receive their rules through the GPO for the zone to which they reside. You must make sure that those rules contain at least one of the data integrity and encryption algorithms that are configured in this rule, or the client devices in that zone won't be able to connect to devices in this zone.
+
+10. If you need to add an algorithm combination, click **Add** and then select the combination of encryption and integrity algorithms. The options are described in [Configure Data Protection (Quick Mode) Settings](configure-data-protection-quick-mode-settings.md).
+
+    **Note**  
+    Not all of the algorithms available in Windows 8 or Windows Server 2012 and later can be selected in the Windows Defender Firewall with Advanced Security user interface. To select them, you can use Windows PowerShell.
+
+    Quick mode settings can also be configured on a per-rule basis, but not by using the Windows Defender Firewall user interface. Instead, you can create or modify the rules by using Windows PowerShell.
+
+    For more info, see [Windows Defender Firewall with Advanced Security Administration with Windows PowerShell](windows-firewall-with-advanced-security-administration-with-windows-powershell.md)
+
+11. During negotiation, algorithm combinations are proposed in the order shown in the list. Ensure that the more secure combinations are at the top of the list so that the negotiating devices select the most secure combination that they can jointly support.
+
+12. Click **OK** three times to save your changes.

windows/security/operating-system-security/network-security/windows-firewall/configure-the-windows-firewall-log.md

@@ -0,0 +1,45 @@
+---
+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.
+
+        >**Important:**  The location you specify must have permissions assigned that permit the Windows Defender Firewall service to write to the log file.
+
+    4.  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.
+
+    5.  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**.
+
+    6.  Click **OK** twice.
+
+### Troubleshooting 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. 

windows/security/operating-system-security/network-security/windows-firewall/configure-the-workstation-authentication-certificate-template.md

@@ -0,0 +1,42 @@
+---
+title: Configure the Workstation Authentication Template 
+description: Learn how to configure a workstation authentication certificate template, which is used for device certificates that are enrolled and deployed to workstations.
+ms.prod: windows-client
+ms.date: 09/07/2021
+ms.topic: conceptual
+---
+
+# Configure the Workstation Authentication Certificate Template
+
+
+This procedure describes how to configure a certificate template that Active Directory Certification Services (AD CS) uses as the starting point for device certificates that are automatically enrolled and deployed to workstations in the domain. It shows how to create a copy of a template, and then configure the template according to your design requirements.
+
+**Administrative credentials**
+
+## To configure the workstation authentication certificate template and autoenrollment
+To complete these procedures, you must be a member of both the Domain Admins group in the root domain of your forest, and a member of the Enterprise Admins group.
+
+
+1.  On the device where AD CS is installed, open the Certification Authority console.
+
+2.  In the navigation pane, right-click **Certificate Templates**, and then click **Manage**.
+
+3.  In the details pane, click the **Workstation Authentication** template.
+
+4.  On the **Action** menu, click **Duplicate Template**. In the **Duplicate Template** dialog box, select the template version that is appropriate for your deployment, and then click **OK**. For the resulting certificates to have maximum compatibility with the available versions of Windows, we recommended that you select **Windows Server 2003**.
+
+5.  On the **General** tab, in **Template display name**, type a new name for the certificate template, such as **Domain Isolation Workstation Authentication Template**.
+
+6.  Click the **Subject Name** tab. Make sure that **Build from this Active Directory information** is selected. In **Subject name format**, select **Fully distinguished name**.
+
+7.  Click the **Cryptography** tab. You must determine the best minimum key size for your environment. Large key sizes provide better security, but they can affect server performance. We recommended that you use the default setting of 2048.
+
+8.  Click the **Security** tab. In **Group or user names**, click **Domain Computers**, under **Allow**, select **Enroll** and **Autoenroll**, and then click **OK**.
+
+    >**Note:**  If you want do not want to deploy the certificate to every device in the domain, then specify a different group or groups that contain the device accounts that you want to receive the certificate.
+
+9.  Close the Certificate Templates Console.
+
+10. In the Certification Authority MMC snap-in, in the left pane, right-click **Certificate Templates**, click **New**, and then click **Certificate Template to Issue**.
+
+11. In the **Enable Certificate Templates** dialog box, click the name of the certificate template you configured, and then click **OK**.

windows/security/operating-system-security/network-security/windows-firewall/configure-windows-firewall-to-suppress-notifications-when-a-program-is-blocked.md

@@ -0,0 +1,40 @@
+---
+title: Configure Windows Defender Firewall with Advanced Security to Suppress Notifications When a Program is Blocked 
+description: Configure Windows Defender Firewall with Advanced Security to suppress notifications when a program is Blocked
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Configure Windows Defender Firewall with Advanced Security to Suppress Notifications When a Program Is Blocked
+
+
+To configure Windows Defender Firewall with Advanced Security to suppress the display of a notification when it blocks a program that tries to listen for network traffic and to prohibit locally defined rules, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console.
+
+>**Caution:**  If you choose to disable alerts and prohibit locally defined rules, then you must create firewall rules that allow your users’ programs to send and receive the required network traffic. If a firewall rule is missing, then the user does not receive any kind of warning, the network traffic is silently blocked, and the program might fail.
+
+We recommend that you don't enable these settings until you've created and tested the required rules.
+
+**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 Windows Defender Firewall to suppress the display of a notification for a blocked program and to ignore locally defined rules
+
+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 **Settings**, click **Customize**.
+
+    3.  Under **Firewall settings**, change **Display a notification** to **No**.
+
+    4.  Under **Rule merging**, change **Apply local firewall rules** to **No**.
+
+    5.  Although a connection security rule isn't a firewall setting, you can also use this tab to prohibit locally defined connection security rules if you're planning to deploy IPsec rules as part of a server or domain isolation environment. Under **Rule merging**, change **Apply local connection security rules** to **No**.
+
+    6.  Click **OK** twice.

windows/security/operating-system-security/network-security/windows-firewall/confirm-that-certificates-are-deployed-correctly.md

@@ -0,0 +1,39 @@
+---
+title: Confirm That Certificates Are Deployed Correctly 
+description: Learn how to confirm that a Group Policy is being applied as expected and that the certificates are being properly installed on the workstations.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 01/24/2023
+---
+
+# Confirm That Certificates Are Deployed Correctly
+
+After configuring your certificates and autoenrollment in Group Policy, you can confirm that the policy is being applied as expected, and that the certificates are being properly installed on the workstation devices.
+
+In these procedures, you refresh Group Policy on a client device, and then confirm that the certificate is deployed correctly.
+
+**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.
+
+In this topic:
+
+-   [Refresh Group Policy on a device](#to-refresh-group-policy-on-a-device)
+-   [Verify that a certificate is installed](#to-verify-that-a-certificate-is-installed)
+
+## To refresh Group Policy on a device
+
+ From an elevated command prompt, run the following command:
+
+``` cmd
+gpupdate /target:computer /force
+```
+
+After Group Policy is refreshed, you can see which GPOs are currently applied to the device.
+
+## To verify that a certificate is installed
+
+1.  Open the Certificates console
+1.  In the navigation pane, expand **Trusted Root Certification Authorities**, and then click **Certificates**
+
+    The CA that you created appears in the list.

windows/security/operating-system-security/network-security/windows-firewall/copy-a-gpo-to-create-a-new-gpo.md

@@ -0,0 +1,46 @@
+---
+title: Copy a GPO to Create a New GPO 
+description: Learn how to make a copy of a GPO by using the Active Directory Users and devices MMC snap-in to create a GPO for boundary zone devices.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Copy a GPO to Create a New GPO
+
+
+To create the GPO for the boundary zone devices, make a copy of the main domain isolation GPO, and then change the settings to request, instead of require, authentication. To make a copy of a GPO, use the Active Directory Users and devices MMC snap-in.
+
+**Administrative credentials**
+
+To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new GPOs.
+
+**To make a copy of a GPO**
+
+1. Open the Group Policy Management console.
+
+2. In the navigation pane, expand **Forest:**<em>YourForestName</em>, expand **Domains**, expand *YourDomainName*, and then click **Group Policy Objects**.
+
+3. In the details pane, right-click the GPO you want to copy, and then click **Copy**.
+
+4. In the navigation pane, right-click **Group Policy Objects** again, and then click **Paste**.
+
+    :::image type="content" alt-text="Screenshot that shows Copy Paste GPO." source="images/grouppolicy-paste.png":::
+
+5. In the **Copy GPO** dialog box, click **Preserve the existing permissions**, and then click **OK**. Selecting this option preserves any exception groups to which you denied Read and Apply GPO permissions, making the change simpler.
+
+6. After the copy is complete, click **OK**. The new GPO is named **Copy of** *original GPO name*.
+
+7. To rename it, right-click the GPO, and then click **Rename**.
+
+8. Type the new name, and then press ENTER.
+
+9. You must change the security filters to apply the policy to the correct group of devices. To change the security filters, click the **Scope** tab, and in the **Security Filtering** section, select the group that grants permissions to all members of the isolated domain, for example **CG\_DOMISO\_IsolatedDomain**, and then click **Remove**.
+
+10. In the confirmation dialog box, click **OK**.
+
+11. Click **Add**.
+
+12. Type the name of the group that contains members of the boundary zone, for example **CG\_DOMISO\_Boundary**, and then click **OK**.
+
+13. If necessary, change the WMI filter to one appropriate for the new GPO. For example, if the original GPO is for client devices running Windows 10 or Windows 11, and the new boundary zone GPO is for devices running Windows Server 2016, then select a WMI filter that allows only those devices to read and apply the GPO.

windows/security/operating-system-security/network-security/windows-firewall/create-a-group-account-in-active-directory.md

@@ -0,0 +1,36 @@
+---
+title: Create a Group Account in Active Directory 
+description: Learn how to create a security group for the computers that are to receive Group Policy settings by using the Active Directory Users and Computers console.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create a Group Account in Active Directory
+
+
+To create a security group to contain the computer accounts for the computers that are to receive a set of Group Policy settings, use the Active Directory Users and Computers console.
+
+**Administrative credentials**
+
+To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new group accounts.
+
+**To add a new membership group in Active Directory**
+
+1.  Open the Active Directory Users and Computers console.
+
+2.  In the navigation pane, select the container in which you want to store your group. This is typically the **Users** container under the domain.
+
+3.  Click **Action**, click **New**, and then click **Group**.
+
+4.  In the **Group name** text box, type the name for your new group.
+
+    >**Note:**  Be sure to use a name that clearly indicates its purpose. Check to see if your organization has a naming convention for groups.
+
+5.  In the **Description** text box, enter a description of the purpose of this group.
+
+6.  In the **Group scope** section, select either **Global** or **Universal**, depending on your Active Directory forest structure. If your group must include computers from multiple domains, then select **Universal**. If all of the members are from the same domain, then select **Global**.
+
+7.  In the **Group type** section, click **Security**.
+
+8.  Click **OK** to save your group.

windows/security/operating-system-security/network-security/windows-firewall/create-a-group-policy-object.md

@@ -0,0 +1,42 @@
+---
+title: Create a Group Policy Object 
+description: Learn how to use the Active Directory Users and Computers MMC snap-in to create a GPO. You must be a member of the Domain Administrators group.
+ms.prod: windows-client
+ms.collection: 
+  - highpri
+  - tier3
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create a Group Policy Object
+
+
+To create a new GPO, use the Active Directory Users and Computers MMC snap-in.
+
+**Administrative credentials**
+
+To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to create new GPOs.
+
+To create a new GPO
+
+1. Open the Group Policy Management console.
+
+2. In the navigation pane, expand **Forest:**<em>YourForestName</em>, expand **Domains**, expand *YourDomainName*, and then click **Group Policy Objects**.
+
+3. Click **Action**, and then click **New**.
+
+4. In the **Name** text box, type the name for your new GPO.
+
+   > [!NOTE]
+   > Be sure to use a name that clearly indicates the purpose of the GPO. Check to see if your organization has a naming convention for GPOs.
+
+5. Leave **Source Starter GPO** set to **(none)**, and then click **OK**.
+
+6. If your GPO will not contain any user settings, then you can improve performance by disabling the **User Configuration** section of the GPO. To do this, perform these steps:
+
+   1.  In the navigation pane, click the new GPO.
+
+   2.  In the details pane, click the **Details** tab.
+
+   3.  Change the **GPO Status** to **User configuration settings disabled**.

windows/security/operating-system-security/network-security/windows-firewall/create-an-authentication-exemption-list-rule.md

@@ -0,0 +1,56 @@
+---
+title: Create an Authentication Exemption List Rule 
+description: Learn how to create rules that exempt devices that cannot communicate by using IPSec from the authentication requirements of your isolation policies.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create an Authentication Exemption List Rule
+
+
+In almost any isolated server or isolated domain scenario, there are some devices or devices that cannot communicate by using IPsec. This procedure shows you how to create rules that exempt those devices from the authentication requirements of your isolation policies.
+
+**Important**  
+Adding devices to the exemption list for a zone reduces security because it permits devices in the zone to send network traffic that is unprotected by IPsec to the devices on the list. As discussed in the Windows Defender Firewall with Advanced Security Design Guide, you must add only managed and trusted devices to the exemption list.
+
+ 
+**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 a rule that exempts specified hosts from authentication**
+
+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 navigation pane, click **Connection Security Rules**.
+
+3.  Click **Action**, and then click **New Rule**.
+
+4.  On the **Rule Type** page of the New Connection Security Rule Wizard, click **Authentication exemption**, and then click **Next**.
+
+5.  On the **Exempt Computers** page, to create a new exemption, click **Add**. To modify an existing exemption, click it, and then click **Edit**.
+
+6.  In the **IP Address** dialog box, do one of the following:
+
+    -   To add a single IP address, click **This IP address or subnet**, type the IP address of the host in the text box, and then click **OK**.
+
+    -   To add an entire subnet by address, click **This IP address or subnet**, and then type the IP address of the subnet, followed by a forward slash (/) and the number of bits in the corresponding subnet mask. For example, **10.50.0.0/16** represents the class B subnet that begins with address 10.50.0.1, and ends with address **10.50.255.254**. Click **OK** when you are finished.
+
+    -   To add the local device’s subnet, click **Predefined set of computers**, select **Local subnet** from the list, and then click **OK**.
+
+        >**Note:**  If you select the local subnet from the list rather than typing the subnet address in manually, the device automatically adjusts the active local subnet to match the device’s current IP address.
+        
+    -   To add a discrete range of addresses that do not correspond to a subnet, click **This IP address range**, type the beginning and ending IP addresses in the **From** and **To** text boxes, and then click **OK**.
+
+    -   To exempt all of the remote hosts that the local device uses for a specified network service, click **Predefined set of computers**, select the network service from the list, and then click **OK**.
+
+7.  Repeat steps 5 and 6 for each exemption that you need to create.
+
+8.  Click **Next** when you have created all of the exemptions.
+
+9.  On the **Profile** page, check the profile for each network location type to which this set of exemptions applies, and then click **Next**.
+
+    >**Caution:**  If all of the exemptions are on the organization’s network and that network is managed by an Active Directory domain, then consider restricting the rule to the Domain profile only. Selecting the wrong profile can reduce the protection for your computer because any computer with an IP address that matches an exemption rule will not be required to authenticate.
+
+10. On the **Name** page, type the name of the exemption rule, type a description, and then click **Finish**.

windows/security/operating-system-security/network-security/windows-firewall/create-an-authentication-request-rule.md

@@ -0,0 +1,78 @@
+---
+title: Create an Authentication Request Rule 
+description: Create a new rule for Windows Defender Firewall with Advanced Security so devices on the network use IPsec protocols and methods before they can communicate.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create an Authentication Request Rule
+
+**Applies to:**
+-   Windows 10
+-   Windows 11
+-   Windows Server 2016 and above
+
+After you have configured IPsec algorithms and authentication methods, you can create the rule that requires the devices on the network to use those protocols and methods before they can communicate.
+
+**Administrative credentials**
+
+To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the (Group Policy Objects) GPOs.
+
+To create the authentication request 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).
+
+2.  In the navigation pane, right-click **Connection Security Rules**, and then click **New Rule**.
+
+3.  On the **Rule Type** page, select **Isolation**, and then click **Next**.
+
+4.  On the **Requirements** page, select **Request authentication for inbound and outbound connections**.
+
+    > [!CAUTION]
+    > Do not configure the rule to require inbound authentication until you have confirmed that all of your devices are receiving the correct GPOs, and are successfully negotiating IPsec and authenticating with each other. Allowing the devices to communicate even when authentication fails prevents any errors in the GPOs or their distribution from breaking communications on your network.
+
+5.  On the **Authentication Method** page, select the authentication option you want to use on your network. To select multiple methods that are attempted in order until one succeeds, click **Advanced**, click **Customize**, and then click **Add** to add methods to the list. Second authentication methods require Authenticated IP (AuthIP).
+
+    1.  **Default**. Selecting this option tells the device to request authentication by using the method currently defined as the default on the device. This default might have been configured when the operating system was installed or it might have been configured by Group Policy. Selecting this option is appropriate when you have configured system-wide settings by using the [Configure Authentication Methods](configure-authentication-methods.md) procedure.
+
+    2.  **Advanced**. Selecting this option enables you to specify a custom combination of authentication methods required for your scenario.
+        
+6.  Optional: If you selected **Advanced** in the previous step, then Click **Customize** to specify a custom combination of authentication methods required for your scenario. You can specify both a **First authentication method** and a **Second authentication method**.
+
+    The **First authentication method** can be one of the following:
+
+    -   **Computer (NTLMv2)**. Selecting this option tells the device to use and require authentication of the device by using its domain credentials. This option works only with other devices that can use AuthIP. User-based authentication using Kerberos V5 is not supported by IKE v1.
+
+    -   **Computer certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the device to request authentication by using a certificate that is issued by the specified CA. If you also select **Accept only health certificates**, then only certificates issued by a NAP server can be used for this rule.
+
+    -   **Preshared key (not recommended)**. Selecting this method and entering a pre-shared key tells the device to authenticate by exchanging the pre-shared keys. If the keys match, then the authentication succeeds. This method is not recommended, and is included for backward compatibility and testing purposes only.
+
+    If you select **First authentication is optional**, then the connection can succeed even if the authentication attempt specified in this column fails.
+
+    The **Second authentication method** can be one of the following:
+
+    -   **User (NTLMv2)**. Selecting this option tells the device to use and require authentication of the currently logged-on user by using his or her domain credentials, and uses the NTLMv2 protocol instead of Kerberos V5. This authentication method works only with other devices that can use AuthIP. User-based authentication using NTLMv2 is not supported by IKE v1.
+
+    -   **User health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the device to request user-based authentication by using a certificate that is issued by the specified CA. If you also select **Enable certificate to account mapping**, then the certificate can be associated with a user in Active Directory for purposes of granting or denying access to certain users or user groups.
+
+    -   **Computer health certificate from this certification authority (CA)**. Selecting this option and entering the identification of a CA tells the device to use and require authentication by using a certificate that is issued by the specified CA. If you also select **Accept only health certificates**, then only certificates issued by a NAP server can be used for this rule.
+
+    If you check **Second authentication is optional**, the connection can succeed even if the authentication attempt specified in this column fails.
+
+    > [!IMPORTANT]
+    > Make sure that you do not select the boxes to make both first and second authentication optional. Doing so allows plaintext connections whenever authentication fails.
+
+7.  After you have configured the authentication methods, click **OK** on each dialog box to save your changes and close it, until you return to the **Authentication Method** page in the wizard. Click **Next**.
+
+8.  On the **Profile** page, select the check boxes for the network location type profiles to which this rule applies.
+
+    -   On portable devices, consider clearing the **Private** and **Public** boxes to enable the device to communicate without authentication when it is away from the domain network.
+
+    -   On devices that do not move from network to network, consider selecting all the profiles. Doing so prevents an unexpected switch in the network location type from disabling the rule.
+
+    Click **Next**.
+
+9.  On the **Name** page, type a name for the connection security rule and a description, and then click **Finish**.
+
+    The new rule appears in the list of connection security rules.

windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-icmp-rule.md

@@ -0,0 +1,56 @@
+---
+title: Create an Inbound ICMP Rule 
+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.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create an Inbound ICMP Rule
+
+
+To allow inbound Internet Control Message Protocol (ICMP) network traffic, 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 ICMP requests and responses to be sent and received by computers on the network.
+
+**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 port rule that allows inbound ICMP network traffic. For other inbound port rule types, see:
+
+-   [Create an Inbound Port Rule](create-an-inbound-port-rule.md)
+
+-   [Create Inbound Rules to Support RPC](create-inbound-rules-to-support-rpc.md)
+
+To create an inbound ICMP 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).
+
+2.  In the navigation pane, click **Inbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
+
+5.  On the **Program** page, click **All programs**, and then click **Next**.
+
+6.  On the **Protocol and Ports** page, select **ICMPv4** or **ICMPv6** from the **Protocol type** list. If you use both IPv4 and IPv6 on your network, you must create a separate ICMP rule for each.
+
+7.  Click **Customize**.
+
+8.  In the **Customize ICMP Settings** dialog box, do one of the following:
+
+    -   To allow all ICMP network traffic, click **All ICMP types**, and then click **OK**.
+
+    -   To select one of the predefined ICMP types, click **Specific ICMP types**, and then select each type in the list that you want to allow. Click **OK**.
+
+    -   To select an ICMP type that does not appear in the list, click **Specific ICMP types**, select the **Type** number from the list, select the **Code** number from the list, click **Add**, and then select the newly created entry from the list. Click **OK**
+
+9.  Click **Next**.
+
+10. 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**.
+
+11. On the **Action** page, select **Allow the connection**, and then click **Next**.
+
+12. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
+
+13. On the **Name** page, type a name and description for your rule, and then click **Finish**.

windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-port-rule.md

@@ -0,0 +1,63 @@
+---
+title: Create an Inbound Port Rule 
+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
+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.
+
+**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**
+
+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 navigation pane, click **Inbound Rules**.
+
+3. Click **Action**, and then click **New rule**.
+
+4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **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**.
+
+   > [!Note]
+   > This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The specified program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. If you choose to do this, follow the steps in the [Create an Inbound Program or Service Rule](create-an-inbound-program-or-service-rule.md) procedure in addition to the steps in this procedure to create a single rule that filters network traffic using both program and port criteria.
+
+6. On the **Protocol and Ports** page, select the protocol type that you want to allow. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this is an incoming rule, you typically configure only the local port number.
+
+   If you select another protocol, then only packets whose protocol field in the IP header match this rule are permitted through the firewall.
+
+   To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box.
+
+   When you have 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 **Allow 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**.
+
+   > [!Note]
+   > If this GPO is targeted at server computers running Windows Server 2008 that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card's cable. A disconnected network card is automatically assigned to the Public network location type.
+   
+10. On the **Name** page, type a name and description for your rule, and then click **Finish**.

windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-program-or-service-rule.md

@@ -0,0 +1,65 @@
+---
+title: Create an Inbound Program or Service Rule 
+description: Learn how to allow inbound traffic to a program or service by using the Group Policy Management MMC snap-in to create firewall rules.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create an Inbound Program or Service Rule
+
+
+To allow inbound network traffic to a specified program or service, use the Windows Defender Firewall with Advanced Securitynode in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows the program to listen and receive inbound network traffic on any port.
+
+>**Note:**  This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. To combine the program and port rule types into a single rule, follow the steps in the [Create an Inbound Port Rule](create-an-inbound-port-rule.md) procedure in addition to the steps in this procedure.
+
+**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 inbound 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).
+
+2.  In the navigation pane, click **Inbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **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 **This program path**.
+
+6.  Type the path to the program in the text box. Use environment variables, where applicable, 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 allowed to receive inbound 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, click **Apply to service with this service short name**, and then type the short name for the service in the text box. Click **OK**, and then click **Next**.
+
+    **Important**  
+    To use the **Apply to this service** or **Apply to service with this service short name** options, the service must be configured with a security identifier (SID) with a type of **RESTRICTED** or **UNRESTRICTED**. To check the SID type of a service, run the following command:
+
+    **sc** **qsidtype** *<ServiceName>*
+
+    If the result is **NONE**, then a firewall rule cannot be applied to that service.
+
+    To set a SID type on a service, run the following command:
+
+    **sc** **sidtype** *<ServiceName> <Type>*
+
+    In the preceding command, the value of *<Type>* can be **UNRESTRICTED** or **RESTRICTED**. Although the command also permits the value of **NONE**, that setting means the service cannot be used in a firewall rule as described here. By default, most services in Windows are configured as **UNRESTRICTED**. If you change the SID type to **RESTRICTED**, the service might fail to start. We recommend that you change the SID type only on services that you want to use in firewall rules, and that you change the SID type to **UNRESTRICTED**.
+
+8.  It is a best practice to restrict the firewall rule for the program to only the ports it needs to operate. On the **Protocols and Ports** page, you can specify the port numbers for the allowed traffic. If the program tries to listen on a port different from the one specified here, it is blocked. For more information about protocol and port options, see [Create an Inbound Port Rule](create-an-inbound-port-rule.md). After 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 **Allow 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**.

windows/security/operating-system-security/network-security/windows-firewall/create-an-outbound-port-rule.md

@@ -0,0 +1,46 @@
+---
+title: Create an Outbound Port Rule 
+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
+
+
+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.
+
+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).
+
+2.  In the navigation pane, click **Outbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Outbound Rule wizard, click **Custom**, and then click **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**.

windows/security/operating-system-security/network-security/windows-firewall/create-an-outbound-program-or-service-rule.md

@@ -0,0 +1,50 @@
+---
+title: Create an Outbound Program or Service Rule 
+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
+---
+
+# 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).
+
+2.  In the navigation pane, click **Outbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Outbound Rule Wizard, click **Custom**, and then click **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**.

windows/security/operating-system-security/network-security/windows-firewall/create-inbound-rules-to-support-rpc.md

@@ -0,0 +1,83 @@
+---
+title: Create Inbound Rules to Support RPC 
+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.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create Inbound Rules to Support RPC
+
+
+To allow inbound remote procedure call (RPC) network traffic, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create two firewall rules. The first rule allows incoming network packets on TCP port 135 to the RPC Endpoint Mapper service. The incoming traffic consists of requests to communicate with a specified network service. The RPC Endpoint Mapper replies with a dynamically assigned port number that the client must use to communicate with the service. The second rule allows the network traffic that is sent to the dynamically assigned port number. Using the two rules configured as described in this topic helps to protect your device by allowing network traffic only from devices that have received RPC dynamic port redirection and to only those TCP port numbers assigned by the RPC Endpoint Mapper.
+
+**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 rules that allow inbound RPC network traffic. For other inbound port rule types, see:
+
+-   [Create an Inbound Port Rule](create-an-inbound-port-rule.md)
+
+-   [Create an Inbound ICMP Rule](create-an-inbound-icmp-rule.md)
+
+In this topic:
+
+-   [To create a rule to allow inbound network traffic to the RPC Endpoint Mapper service](#to-create-a-rule-to-allow-inbound-network-traffic-to-the-rpc-endpoint-mapper-service)
+
+-   [To create a rule to allow inbound network traffic to RPC-enabled network services](#to-create-a-rule-to-allow-inbound-network-traffic-to-rpc-enabled-network-services)
+
+## To create a rule to allow inbound network traffic to the RPC Endpoint Mapper 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).
+
+2.  In the navigation pane, click **Inbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
+
+5.  On the **Program** page, click **This Program Path**, and then type **%systemroot%\\system32\\svchost.exe**.
+
+6.  Click **Customize**.
+
+7.  In the **Customize Service Settings** dialog box, click **Apply to this service**, select **Remote Procedure Call (RPC)** with a short name of **RpcSs**, click **OK**, and then click **Next**.
+
+8.  On the warning about Windows service-hardening rules, click **Yes**.
+
+9.  On the **Protocol and Ports** dialog box, for **Protocol type**, select **TCP**.
+
+10. For **Local port**, select **RPC Endpoint Mapper**, and then click **Next**.
+
+11. 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**.
+
+12. On the **Action** page, select **Allow the connection**, and then click **Next**.
+
+13. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.   
+
+14. On the **Name** page, type a name and description for your rule, and then click **Finish**.
+
+
+## To create a rule to allow inbound network traffic to RPC-enabled network services
+
+1.  On the same GPO you edited in the preceding procedure, click **Action**, and then click **New rule**.
+
+2.  On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
+
+3.  On the **Program** page, click **This Program Path**, and then type the path to the executable file that hosts the network service. Click **Customize**.
+
+4.  In the **Customize Service Settings** dialog box, click **Apply to this service**, and then select the service that you want to allow. If the service doesn't appear in the list, then click **Apply to service with this service short name**, and then type the short name of the service in the text box.
+
+5.  Click **OK**, and then click **Next**.
+
+6.  On the **Protocol and Ports** dialog box, for **Protocol type**, select **TCP**.
+
+7.  For **Local port**, select **RPC Dynamic Ports**, and then click **Next**.
+
+8.  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**.
+
+9.  On the **Action** page, select **Allow the connection**, and then click **Next**.
+
+10. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
+
+11. On the **Name** page, type a name and description for your rule, and then click **Finish**.

windows/security/operating-system-security/network-security/windows-firewall/create-windows-firewall-rules-in-intune.md

@@ -0,0 +1,102 @@
+---
+title: Create Windows Firewall rules in Intune 
+description: Learn how to use Intune to create rules in Windows Defender Firewall with Advanced Security. Start by creating a profile in Device Configuration in Intune.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 12/31/2017
+---
+
+# Create Windows Firewall rules in Intune
+
+
+>[!IMPORTANT]
+>This information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
+
+To get started, Open the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), and then go to **Devices** > **Windows** > **Configuration profiles** > **Create profile** > Choose **Windows 10 and later** as the platform, Choose **Templates**, then **Endpoint protection** as the profile type. 
+Select Windows Defender Firewall.
+:::image type="content" source="images/windows-firewall-intune.png" alt-text="Example of a Windows Defender Firewall policy in Microsoft Intune and the Intune admin center.":::
+
+>[!IMPORTANT]
+>A single Endpoint Protection profile may contain up to a maximum of 150 firewall rules. If a client device requires more than 150 rules, then multiple profiles must be assigned to it.
+
+## Firewall rule components
+
+The firewall rule configurations in Intune use the Windows CSP for Firewall. For more information, see [Firewall CSP](/windows/client-management/mdm/firewall-csp).
+
+## Application
+Control connections for an app or program. 
+Apps and programs can be specified either file path, package family name, or Windows service short name. 
+
+The file path of an app is its location on the client device. 
+For example, C:\Windows\System\Notepad.exe. 
+[Learn more](/windows/client-management/mdm/firewall-csp#filepath) 
+
+Package family names can be retrieved by running the Get-AppxPackage command from PowerShell. 
+[Learn more](https://aka.ms/intunefirewallPackageNameFromPowerShell) 
+
+Windows service short names are used in cases when a service, not an application, is sending or receiving traffic. 
+Default is All. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#servicename)
+
+## Protocol
+Select the protocol for this port rule. Transport layer protocols—TCP and UDP—allow you to specify ports or port ranges. For custom protocols, enter a number between 0 and 255 representing the IP protocol. 
+
+Default is Any. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#protocol)
+
+## Local ports
+Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#localportranges)
+
+## Remote ports
+Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#remoteportranges)
+
+## Local addresses
+Comma-separated list of local addresses covered by the rule. Valid tokens include:
+- \* indicates any local address. If present, this token must be the only one included. 
+- A subnet can be specified using either the subnet mask or network prefix notation. If a subnet mask or a network prefix isn't specified, the subnet mask default is 255.255.255.255. 
+- A valid IPv6 address. 
+- An IPv4 address range in the format of "start address-end address" with no spaces included. 
+- An IPv6 address range in the format of "start address-end address" with no spaces included. Default is Any address. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#localaddressranges)
+
+## Remote addresses
+List of comma separated tokens specifying the remote addresses covered by the rule. Tokens are case insensitive. Valid tokens include:
+- \* indicates any remote address. If present, this token must be the only one included. 
+- Defaultgateway 
+- DHCP 
+- DNS 
+- WINS 
+- Intranet (supported on Windows versions 1809+) 
+- RmtIntranet (supported on Windows versions 1809+) 
+- Internet (supported on Windows versions 1809+) 
+- Ply2Renders (supported on Windows versions 1809+) 
+- LocalSubnet indicates any local address on the local subnet. 
+- A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255. 
+- A valid IPv6 address. 
+- An IPv4 address range in the format of "start address-end address" with no spaces included. 
+- An IPv6 address range in the format of "start address-end address" with no spaces included. 
+
+Default is Any address. 
+
+[Learn more](https://aka.ms/intunefirewallremotaddressrule)
+
+## Edge traversal (UI coming soon)
+Indicates whether edge traversal is enabled or disabled for this rule. The EdgeTraversal setting indicates that specific inbound traffic is allowed to tunnel through NATs and other edge devices using the Teredo tunneling technology. In order for this setting to work correctly, the application or service with the inbound firewall rule needs to support IPv6. The primary application of this setting allows listeners on the host to be globally addressable through a Teredo IPv6 address. New rules have the EdgeTraversal property disabled by default. This setting can only be configured via Intune Graph at this time. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#edgetraversal)
+
+## Authorized users
+Specifies the list of authorized local users for this rule. A list of authorized users can't be specified if the rule being authored is targeting a Windows service. Default is all users. 
+
+[Learn more](/windows/client-management/mdm/firewall-csp#localuserauthorizedlist)
+
+## Configuring firewall rules programmatically
+
+Coming soon.

windows/security/operating-system-security/network-security/windows-firewall/create-wmi-filters-for-the-gpo.md

@@ -0,0 +1,98 @@
+---
+title: Create WMI Filters for the GPO 
+description: Learn how to use WMI filters on a GPO to make sure that each GPO for a group can only be applied to devices running the correct version of Windows.
+ms.prod: windows-client
+ms.collection: 
+  - highpri
+  - tier3
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Create WMI Filters for the GPO
+
+
+To make sure that each GPO associated with a group can only be applied to devices running the correct version of Windows, use the Group Policy Management MMC snap-in to create and assign WMI filters to the GPO. Although you can create a separate membership group for each GPO, you would then have to manage the memberships of the different groups. Instead, use only a single membership group, and let WMI filters automatically ensure the correct GPO is applied to each device.
+
+- [Create WMI Filters for the GPO](#create-wmi-filters-for-the-gpo)
+   - [To create a WMI filter that queries for a specified version of Windows](#to-create-a-wmi-filter-that-queries-for-a-specified-version-of-windows)
+   - [To link a WMI filter to a GPO](#to-link-a-wmi-filter-to-a-gpo)
+
+**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.
+
+First, create the WMI filter and configure it to look for a specified version (or versions) of the Windows operating system.
+
+## To create a WMI filter that queries for a specified version of Windows
+
+1.  Open the Group Policy Management console.
+
+2.  In the navigation pane, expand **Forest:** *YourForestName*, expand **Domains**, expand *YourDomainName*, and then select **WMI Filters**.
+
+3.  Select **Action**, and then select **New**.
+
+4.  In the **Name** text box, type the name of the WMI filter. Be sure to use a name that clearly indicates the purpose of the filter. Check to see if your organization has a naming convention.
+
+5.  In the **Description** text box, type a description for the WMI filter. For example, if the filter excludes domain controllers, you might consider stating that in the description.
+
+6.  Select **Add**.
+
+7.  Leave the **Namespace** value set to **root\\CIMv2**.
+
+8.  In the **Query** text box, type:
+
+    ``` syntax
+    select * from Win32_OperatingSystem where Version like "6.%"
+    ```
+
+    This query will return **true** for devices running at least Windows Vista and Windows Server 2008. To set a filter for just Windows 8 and Windows Server 2012, use "6.2%". For Windows 11, Windows 10, and Windows Server 2016, use "10.%". To specify multiple versions, combine them with or, as shown in the following:
+
+    ``` syntax
+    ... where Version like "6.1%" or Version like "6.2%"
+    ```
+
+    To restrict the query to only clients or only servers, add a clause that includes the ProductType parameter. To filter for client operating systems only, such as Windows 8 or Windows 7, use only ProductType="1". For server operating systems that are not domain controllers and for Windows 10 and Windows 11 multi-session, use ProductType="3". For domain controllers only, use ProductType="2". This is a useful distinction, because you often want to prevent your GPOs from being applied to the domain controllers on your network.
+
+    The following clause returns **true** for all devices that are not domain controllers:
+
+    ``` syntax
+    ... where ProductType="1" or ProductType="3"
+    ```
+
+    The following complete query returns **true** for all devices running Windows 10 and Windows 11, and returns **false** for any server operating system or any other client operating system.
+
+    ``` syntax
+    select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"
+    ```
+
+    Specific versions of Windows 10 can be targeted by including the *major build version* in the query. The following query returns **true** for all devices running Windows 10 20H2 (which has a *major build version* of `19042`), and returns **false** for any server operating system or any other client operating system. Additional information about Windows 10 build versions can be found at [Windows 10 release information](/windows/release-health/release-information).
+
+    ```syntax
+    select * from Win32_OperatingSystem where Version like "10.0.19042" and ProductType="1"
+    ```
+
+    The following query returns **true** for any device running Windows Server 2016, except domain controllers:
+
+    ``` syntax
+    select * from Win32_OperatingSystem where Version like "10.%" and ProductType="3"
+    ```
+
+9.  Select **OK** to save the query to the filter.
+
+10. Select **Save** to save your completed filter.
+
+> [!NOTE]
+> If you're using multiple queries in the same WMI filter, these queries must all return **TRUE** for the filter requirements to be met and for the GPO to be applied.
+
+## To link a WMI filter to a GPO
+
+After you have created a filter with the correct query, link the filter to the GPO. Filters can be reused with many GPOs simultaneously; you do not have to create a new one for each GPO if an existing one meets your needs.
+
+1.  Open the Group Policy Management console.
+
+2.  In the navigation pane, find and then select the GPO that you want to modify.
+
+3.  Under **WMI Filtering**, select the correct WMI filter from the list.
+
+4.  Select **Yes** to accept the filter.

windows/security/operating-system-security/network-security/windows-firewall/designing-a-windows-firewall-with-advanced-security-strategy.md

@@ -0,0 +1,41 @@
+---
+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 Kerberos V5 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)

windows/security/operating-system-security/network-security/windows-firewall/determining-the-trusted-state-of-your-devices.md

@@ -0,0 +1,133 @@
+---
+title: Determining the Trusted State of Your Devices 
+description: Learn how to define the trusted state of devices in your enterprise to help design your strategy for using Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Determining the Trusted State of Your Devices
+
+
+After obtaining information about the devices that are currently part of the IT infrastructure, you must determine at what point a device is considered trusted. The term *trusted* can mean different things to different people. Therefore, you must communicate a firm definition for it to all stakeholders in the project. Failure to do this communication can lead to problems with the security of the trusted environment, because the overall security can't exceed the level of security set by the least secure client that achieves trusted status.
+
+>**Note:**  In this context, the term *trust* has nothing to do with an Active Directory trust relationship between domains. The trusted state of your devices just indicates the level of risk that you believe the device brings to the network. Trusted devices bring little risk whereas untrusted devices can potentially bring great risk.
+
+## Trust states
+
+
+To understand this concept, consider the four basic states that apply to devices in a typical IT infrastructure. These states are (in order of risk, lowest risk first):
+
+-   Trusted
+
+-   Trustworthy
+
+-   Known, untrusted
+
+-   Unknown, untrusted
+
+The remainder of this section defines these states and how to determine which devices in your organization belong in each state.
+
+### Trusted state
+
+Classifying a device as trusted means that the device's security risks are managed, but it doesn't imply that it's perfectly secure or invulnerable. The responsibility for this managed state falls to the IT and security administrators, in addition to the users who are responsible for the configuration of the device. A trusted device that is poorly managed will likely become a point of weakness for the network.
+
+When a device is considered trusted, other trusted devices can reasonably assume that the device won't initiate a malicious act. For example, trusted devices can expect that other trusted devices won't run a virus that attacks them, because all trusted devices are required to use mechanisms (such as antivirus software) to mitigate the threat of viruses.
+
+Spend some time defining the goals and technology requirements that your organization considers appropriate as the minimum configuration for a device to obtain trusted status.
+
+A possible list of technology requirements might include:
+
+-   **Operating system.** A trusted client device should run at least Windows Vista. A trusted server should run at least Windows Server 2008.
+
+-   **Domain membership.** A trusted device will belong to a managed Active Directory domain, which means that the IT department has security management rights and can configure member devices by using Group Policy.
+
+-   **Management client.** All trusted devices must run a specific network management client to allow for centralized management and control of security policies, configurations, and software. Configuration Manager is one such management system with an appropriate client.
+
+-   **Antivirus software.** All trusted devices will run antivirus software that is configured to check for and automatically update the latest virus signature files daily.
+
+-   **File system.** All trusted devices will be configured to use the NTFS file system.
+
+-   **BIOS settings.** All trusted portable devices will be configured to use a BIOS-level password that is under the management of the IT support team.
+
+-   **Password requirements.** Trusted clients must use strong passwords.
+
+It's important to understand that the trusted state isn't constant; it's a transient state that is subject to changing security standards and compliance with those standards. New threats and new defenses emerge constantly. For this reason, the organization's management systems must continually check the trusted devices to ensure ongoing compliance. Additionally, the management systems must be able to issue updates or configuration changes if they're required to help maintain the trusted status.
+
+A device that continues to meet all these security requirements can be considered trusted. However it's possible that most devices that were identified in the discovery process discussed earlier don't meet these requirements. Therefore, you must identify which devices can be trusted and which ones can't. To help with this process, you use the intermediate *trustworthy* state. The remainder of this section discusses the different states and their implications.
+
+### Trustworthy state
+
+It's useful to identify as soon as possible those devices in your current infrastructure that can achieve a trusted state. A *trustworthy state* can be assigned to indicate that the current device can physically achieve the trusted state with required software and configuration changes.
+
+For each device that is assigned a trustworthy status, make an accompanying configuration note that states what is required to enable the device to achieve trusted status. This information is especially important to both the project design team (to estimate the costs of adding the device to the solution) and the support staff (to enable them to apply the required configuration).
+
+Generally, trustworthy devices fall into one of the following two groups:
+
+-   **Configuration required.** The current hardware, operating system, and software enable the device to achieve a trustworthy state. However, more configuration changes are required. For example, if the organization requires a secure file system before a device can be considered trusted, a device that uses a FAT32-formatted hard disk doesn't meet this requirement.
+
+-   **Upgrade required.** These devices require upgrades before they can be considered trusted. The following list provides some examples of the type of upgrade these devices might require:
+
+    -   **Operating system upgrade required.** If the device's current operating system can't support the security needs of the organization, an upgrade would be required before the device could achieve a trusted state.
+
+    -   **Software required.** A device that is missing a required security application, such as an antivirus scanner or a management client, can't be considered trusted until these applications are installed and active.
+
+    -   **Hardware upgrade required.** In some cases, a device might require a specific hardware upgrade before it can achieve trusted status. This type of device usually needs an operating system upgrade or another software that forces the required hardware upgrade. For example, security software might require more hard disk space on the device.
+
+    -   **Device replacement required.** This category is reserved for devices that can't support the security requirements of the solution because their hardware can't support the minimum acceptable configuration. For example, a device that can't run a secure operating system because it has an old processor (such as a 100 megahertz \[MHz\] x86-based device).
+
+Use these groups to assign costs for implementing the solution on the devices that require upgrades.
+
+### Known, untrusted state
+
+During the process of categorizing an organization's devices, you'll identify some devices that can't achieve trusted status for specific well-understood and well-defined reasons. These reasons might include the following types:
+
+-   **Financial.** The funding isn't available to upgrade the hardware or software for this device.
+
+-   **Political.** The device must remain in an untrusted state because of a political or business situation that doesn't enable it to comply with the stated minimum security requirements of the organization. It's highly recommended that you contact the business owner or independent software vendor (ISV) for the device to discuss the added value of server and domain isolation.
+
+-   **Functional.** The device must run a nonsecure operating system or must operate in a nonsecure manner to perform its role. For example, the device might be required to run an older operating system because a specific line of business application will only work on that operating system.
+
+There can be multiple functional reasons for a device to remain in the known untrusted state. The following list includes several examples of functional reasons that can lead to a classification of this state:
+
+-   **Devices that run unsupported versions of Windows.** These versions include Windows XP, Windows Millennium Edition, Windows 98, Windows 95, or Windows NT. Devices that run these versions of the Windows operating system can't be classified as trustworthy because these operating systems don't support the required security infrastructure. For example, although Windows NT does support a basic security infrastructure, it doesn't support “deny” ACLs on local resources, any way to ensure the confidentiality and integrity of network communications, smart cards for strong authentication, or centralized management of device configurations (although limited central management of user configurations is supported).
+
+-   **Stand-alone devices.** Devices running any version of Windows which are configured as stand-alone devices or as members of a workgroup usually can't achieve a trustworthy state. Although these devices fully support the minimum required basic security infrastructure, the required security management capabilities are unlikely to be available when the device isn't a part of a trusted domain.
+
+-   **Devices in an untrusted domain.** A device that is a member of a domain that isn't trusted by an organization's IT department can't be classified as trusted. An untrusted domain is a domain that can't provide the required security capabilities to its members. Although the operating systems of devices that are members of this untrusted domain might fully support the minimum required basic security infrastructure, the required security management capabilities can't be fully guaranteed when devices aren't in a trusted domain.
+
+### Unknown, untrusted state
+
+The unknown, untrusted state should be considered the default state for all devices. Because devices in this state have a configuration that is unknown, you can assign no trust to them. All planning for devices in this state must assume that the device is an unacceptable risk to the organization. Designers of the solution should strive to minimize the impact that the devices in this state can have on their organizations.
+
+## Capturing upgrade costs for current devices
+
+
+The final step in this part of the process is to record the approximate cost of upgrading the devices to a point that they can participate in the server and domain isolation design. You must make several key decisions during the design phase of the project that require answers to the following questions:
+
+-   Does the device meet the minimum hardware requirements necessary for isolation?
+
+-   Does the device meet the minimum software requirements necessary for isolation?
+
+-   What configuration changes must be made to integrate this device into the isolation solution?
+
+-   What is the projected cost or impact of making the proposed changes to enable the device to achieve a trusted state?
+
+By answering these questions, you can quickly determine the level of effort and approximate cost of bringing a particular device or group of devices into the scope of the project. It's important to remember that the state of a device is transitive, and that by performing the listed remedial actions you can change the state of a device from untrusted to trusted. After you decide whether to place a device in a trusted state, you're ready to begin planning and designing the isolation groups, which the next section [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) discusses.
+
+The following table is an example of a data sheet that you could use to help capture the current state of a device and what would be required for the device to achieve a trusted state.
+
+| Device name | Hardware reqs met | Software reqs met | Configuration required | Details | Projected cost |
+| - | - | - | - | - | - |
+| CLIENT001 | No| No| Upgrade hardware and software.| Current operating system is Windows XP. Old hardware isn't compatible with newer versions of Windows.| $??| 
+| SERVER001 | Yes| No| Join trusted domain and upgrade from Windows Server 2003 to Windows Server 2012.| No antivirus software present.| $??| 
+
+In the previous table, the device CLIENT001 is currently "known, untrusted" because its hardware must be upgraded. However, it could be considered trustworthy if the required upgrades are possible. However, if many devices require the same upgrades, the overall cost of the solution would be much higher.
+
+The device SERVER001 is "trustworthy" because it meets the hardware requirements but its operating system must be upgraded. It also requires antivirus software. The projected cost is the amount of effort that is required to upgrade the operating system and install antivirus software, along with their purchase costs.
+
+With the other information that you've gathered in this section, this information will be the foundation of the efforts performed later in the [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) section.
+
+The costs identified in this section only capture the projected cost of the device upgrades. Many more design, support, test, and training costs should be accounted for in the overall project plan.
+
+**Next:** [Planning Your Windows Defender Firewall with Advanced Security Design](planning-your-windows-firewall-with-advanced-security-design.md)

windows/security/operating-system-security/network-security/windows-firewall/documenting-the-zones.md

@@ -0,0 +1,21 @@
+---
+title: Documenting the Zones 
+description: Learn how to document the zone placement of devices in your design for Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Documenting the Zones
+
+
+Generally, the task of determining zone membership isn't complex, but it can be time-consuming. Use the information generated during the [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md) section of this guide to determine the zone in which to put each host. You can document this zone placement by adding a Group column to the inventory table shown in the Designing a Windows Defender Firewall with Advanced Security Strategy section. A sample is shown here:
+
+| Host name | Hardware reqs met | Software reqs met | Configuration required | Details | Projected cost | Group |
+| - | - | - | - | - | - |
+| CLIENT001 | No| No| Upgrade hardware and software.| Current operating system is Windows XP. Old hardware not compatible with newer versions of Windows.| $??| Isolated domain| 
+| SERVER002 | Yes| No| Join trusted domain, upgrade from Windows Server 2008 to at least Windows Server 2012| No antivirus software present.| $??| Encryption| 
+| SENSITIVE001 | Yes| Yes| Not required.| Running Windows Server 2012. Ready for inclusion.| $0| Isolated server (in zone by itself)| 
+| PRINTSVR1 | Yes| Yes| Not required.| Running Windows Server 2008 R2. Ready for inclusion.| $0| Boundary| 
+
+**Next:** [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md)

windows/security/operating-system-security/network-security/windows-firewall/domain-isolation-policy-design-example.md

@@ -0,0 +1,52 @@
+---
+title: Domain Isolation Policy Design Example 
+description: This example uses a fictitious company to illustrate domain isolation policy design in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Domain Isolation Policy Design Example
+
+
+This design example continues to use the fictitious company Woodgrove Bank, and builds on the example described in the [Firewall Policy Design Example](firewall-policy-design-example.md) section. See that example for an explanation of the basic corporate network infrastructure at Woodgrove Bank with diagrams.
+
+## Design Requirements
+
+In addition to the basic protection provided by the firewall rules in the previous design example, you might want to implement domain isolation to provide another layer of security to their networked devices. You can create firewall and connection security rules that use authentication to reduce the risk of communicating with untrusted and potentially hostile devices.
+
+The following illustration shows the traffic protection needed for this design example.
+
+![domain isolation policy design.](images/wfas-design2example1.gif)
+
+1.  All devices on the Woodgrove Bank corporate network that are Active Directory domain members must authenticate inbound network traffic as coming from another computer that is a member of the domain. Unless otherwise specified in this section, Woodgrove Bank's devices reject all unsolicited inbound network traffic that isn't authenticated. If the basic firewall design is also implemented, even authenticated inbound network traffic is dropped unless it matches an inbound firewall rule.
+
+2.  The servers hosting the WGPartner programs must be able to receive unsolicited inbound traffic from devices owned by its partners, which aren't members of Woodgrove Bank's domain.
+
+3.  Client devices can initiate non-authenticated outbound communications with devices that aren't members of the domain, such as browsing external Web sites. Unsolicited inbound traffic from non-domain members is blocked.
+
+4.  Devices in the encryption zone require that all network traffic inbound and outbound must be encrypted, in addition to the authentication already required by the isolated domain.
+
+**Other traffic notes:**
+
+-   All of the design requirements described in the [Firewall Policy Design Example](firewall-policy-design-example.md) section are still enforced.
+
+## Design Details
+
+Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the devices on its network.
+
+Setting up groups as described here ensures that you don't have to know what operating system a computer is running before assigning it to a group. As in the firewall policy design, a combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs.
+
+The following groups were created by using the Active Directory Users and Computers MMC snap-in, all devices that run Windows were added to the correct groups, and then the appropriate GPO are applied to the group. To include a device in the isolated domain or any one of its subordinate zones, add the device's account in the appropriate group.
+
+-   **CG\_DOMISO\_ISOLATEDDOMAIN**. The members of this group participate in the isolated domain. After an initial pilot period, followed by a slowly increasing group membership, the membership of this group was eventually replaced with the entry **Domain Computers** to ensure that all devices in the domain participate by default. The WMI filters ensure that the GPO doesn't apply to domain controllers. GPOs with connection security rules to enforce domain isolation behavior are linked to the domain container and applied to the devices in this group. Filters ensure that each computer receives the correct GPO for its operating system type. The rules in the domain isolation GPO require Kerberos v5 authentication for inbound network connections, and request (but not require) it for all outbound connections.
+
+-   **CG\_DOMISO\_NO\_IPSEC**. This group is denied read or apply permissions on any of the domain isolation GPOs. Any computer that can't participate in domain isolation, such as a DHCP server running UNIX, is added to this group.
+
+-   **CG\_DOMISO\_BOUNDARY**. This group contains the computer accounts for all the devices that are part of the boundary group able to receive unsolicited inbound traffic from untrusted devices. Members of the group receive a GPO that configures connection security rules to request (but not require) both inbound and outbound authentication.
+
+-   **CG\_DOMISO\_ENCRYPTION**. This group contains the computer accounts for all the devices that require all inbound and outbound traffic to be both authenticated and encrypted. Members of the group receive a GPO that configures connection security and firewall rules to require both authentication and encryption on all inbound and outbound traffic.
+
+>**Note:**  If you are designing GPOs for only Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, devices that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any devices that are incorrectly assigned to more than one group.
+
+**Next:** [Server Isolation Policy Design Example](server-isolation-policy-design-example.md)

windows/security/operating-system-security/network-security/windows-firewall/domain-isolation-policy-design.md

@@ -0,0 +1,58 @@
+---
+title: Domain Isolation Policy Design 
+description: Learn how to design a domain isolation policy, based on which devices accept only connections from authenticated members of the same isolated domain.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Domain Isolation Policy Design
+
+
+In the domain isolation policy design, you configure the devices on your network to accept only connections coming from devices that are authenticated as members of the same isolated domain.
+
+This design typically begins with a network configured as described in the [Basic Firewall Policy Design](basic-firewall-policy-design.md) section. For this design, you then add connection security and IPsec rules to configure devices in the isolated domain to accept only network traffic from other devices that can authenticate as a member of the isolated domain. After the new rules are implemented, your devices reject unsolicited network traffic from devices that aren't members of the isolated domain.
+
+The isolated domain might not be a single Active Directory domain. It can consist of all the domains in a forest, or domains in separate forests that have two-way trust relationships configured between them.
+
+By using connection security rules based on IPsec, you provide a logical barrier between devices even if they're connected to the same physical network segment.
+
+The design is shown in the following illustration, with the arrows that show the permitted communication paths.
+
+![isolated domain boundary zone.](images/wfasdomainisoboundary.gif)
+
+Characteristics of this design, as shown in the diagram, include:
+
+-   Isolated domain (area A) - Devices in the isolated domain receive unsolicited inbound traffic only from other members of the isolated domain or from devices referenced in authentication exemption rules. Devices in the isolated domain can send traffic to any device. This traffic includes unauthenticated traffic to devices that aren't in the isolated domain. Devices that can't join an Active Directory domain, but that can use certificates for authentication, can be part of the isolated domain. For more info, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
+
+-   Boundary zone (area B) - Devices in the boundary zone are part of the isolated domain but are allowed to accept inbound connections from untrusted devices, such as clients on the Internet.
+
+    Devices in the boundary zone request but don't require authentication to communicate. When a member of the isolated domain communicates with a boundary zone member, the traffic is authenticated. When a device that isn't part of the isolated domain communicates with a boundary zone member the traffic isn't authenticated.
+
+    Because boundary zone devices are exposed to network traffic from untrusted and potentially hostile devices, they must be carefully managed and secured. Put only the devices that must be accessed by external devices in this zone. Use firewall rules to ensure that network traffic is accepted only for services that you want exposed to non-domain member devices.
+
+-   Trusted non-domain members (area C) - Devices on the network that aren't domain members or that can't use IPsec authentication are allowed to communicate by configuring authentication exemption rules. These rules enable devices in the isolated domain to accept inbound connections from these trusted non-domain member devices.
+
+-   Untrusted non-domain members (area D) - Devices that aren't managed by your organization and have an unknown security configuration must have access only to those devices required for your organization to correctly conduct its business. Domain isolation exists to put a logical barrier between these untrusted Devices and your organization's devices.
+
+After this design is implemented, your administrative team will have centralized management of the firewall and connection security rules applied to the devices in your organization.
+> [!IMPORTANT]
+> This design builds on the [Basic Firewall Policy Design](basic-firewall-policy-design.md), and in turn serves as the foundation for the [Server Isolation Policy Design](server-isolation-policy-design.md). If you plan to deploy all three, we recommend that you do the design work for all three together, and then deploy in the sequence presented.
+
+This design can be applied to Devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the connection security rules.
+
+In order to expand the isolated domain to include Devices that can't be part of an Active Directory domain, see the [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md).
+
+For more info about this design:
+
+-   This design coincides with the implementation goals to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md), [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md), and optionally [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
+
+-   To learn more about this design, see the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md).
+
+-   Before completing the design, gather the info described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
+
+-   To help you make the decisions required in this design, see [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) and [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md).
+
+-   For a list of tasks that you can use to deploy your domain isolation policy design, see [Checklist: Implementing a Domain Isolation Policy Design](checklist-implementing-a-domain-isolation-policy-design.md).
+
+**Next:** [Server Isolation Policy Design](server-isolation-policy-design.md)

windows/security/operating-system-security/network-security/windows-firewall/enable-predefined-inbound-rules.md

@@ -0,0 +1,30 @@
+---
+title: Enable Predefined Inbound Rules 
+description: Learn the rules for Windows Defender Firewall with Advanced Security for common networking roles and functions.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Enable Predefined Inbound Rules
+
+
+Windows Defender Firewall with Advanced Security includes many predefined rules for common networking roles and functions. When you install a new server role on a device or enable a network feature on a client device, the installer typically enables the rules required for that role instead of creating new ones. When deploying firewall rules to the devices on the network, you can take advantage of these predefined rules instead of creating new ones. Using this advantage helps to ensure consistency and accuracy, because the rules have been thoroughly tested and are ready for use.
+
+**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 deploy predefined firewall rules that allow inbound network traffic for common network functions
+
+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 navigation pane, click **Inbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Inbound Rule Wizard, click **Predefined**, select the rule category from the list, and then click **Next**.
+
+5.  On the **Predefined Rules** page, the list of rules defined in the group is displayed. By default, they're all selected. For rules that you don't want to deploy, clear the check boxes next to the rules, and then click **Next**.
+
+6.  On the **Action** page, select **Allow the connection**, and then click **Finish**.

windows/security/operating-system-security/network-security/windows-firewall/enable-predefined-outbound-rules.md

@@ -0,0 +1,32 @@
+---
+title: Enable Predefined Outbound Rules 
+description: Learn to deploy predefined firewall rules that block outbound network traffic for common network functions in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/07/2021
+---
+
+# Enable Predefined Outbound Rules
+
+
+By default, Windows Defender Firewall with Advanced Security allows all outbound network traffic unless it matches a rule that prohibits the traffic. Windows Defender Firewall includes many predefined outbound rules that can be used to block network traffic for common networking roles and functions. When you install a new server role on a computer or enable a network feature on a client computer, the installer can install, but typically doesn't enable, outbound block rules for that role. When deploying firewall rules to the computers on the network, you can take advantage of these predefined rules instead of creating new ones. Using this advantage helps to ensure consistency and accuracy, because the rules have been thoroughly tested and are ready for use.
+
+**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 deploy predefined firewall rules that block outbound network traffic for common network functions
+
+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 navigation pane, click **Outbound Rules**.
+
+3.  Click **Action**, and then click **New rule**.
+
+4.  On the **Rule Type** page of the New Inbound Rule Wizard, click **Predefined**, select the rule category from the list, and then click **Next**.
+
+5.  On the **Predefined Rules** page, the list of rules defined in the group is displayed. They're all selected by default. For rules that you don't want to deploy, clear the check boxes next to the rules, and then click **Next**.
+
+6.  On the **Action** page, select **Block the connection**, and then click **Finish**.
+
+    The selected rules are added to the GPO.

windows/security/operating-system-security/network-security/windows-firewall/encryption-zone-gpos.md

@@ -0,0 +1,16 @@
+---
+title: Encryption Zone GPOs 
+description: Learn how to add a device to an encryption zone by adding the device account to the encryption zone group in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Encryption Zone GPOs
+
+
+Handle encryption zones in a similar manner to the boundary zones. A device is added to an encryption zone by adding the device account to the encryption zone group. Woodgrove Bank has a single service that must be protected, and the devices that are running that service are added to the group CG\_DOMISO\_Encryption. This group is granted Read and Apply Group Policy permissions in on the GPO described in this section.
+
+The GPO is only for server versions of Windows. Client devices aren't expected to participate in the encryption zone. If the need for one occurs, either create a new GPO for that version of Windows or expand the WMI filter attached to one of the existing encryption zone GPOs to make it apply to the client version of Windows.
+
+-   [GPO\_DOMISO\_Encryption](gpo-domiso-encryption.md)

windows/security/operating-system-security/network-security/windows-firewall/encryption-zone.md

@@ -0,0 +1,56 @@
+---
+title: Encryption Zone 
+description: Learn how to create an encryption zone to contain devices that host sensitive data and require that the sensitive network traffic be encrypted.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Encryption Zone
+
+
+Some servers in the organization host data that's sensitive, including medical, financial, or other personal data. Government or industry regulations might require that this sensitive information must be encrypted when it's transferred between devices.
+
+To support the other security requirements of these servers, we recommend that you create an encryption zone to contain the devices and that requires that the sensitive inbound and outbound network traffic is encrypted.
+
+You must create a group in Active Directory to contain members of the encryption zone. The settings and rules for the encryption zone are typically similar to those settings and rules for the isolated domain, and you can save time and effort by copying those GPOs to serve as a starting point. You then modify the security methods list to include only algorithm combinations that include encryption protocols.
+
+Creation of the group and how to link it to the GPOs that apply the rules to members of the group are discussed in the [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section.
+
+## GPO settings for encryption zone servers running at least Windows Server 2008
+
+
+The GPO for devices that are running at least Windows Server 2008 should include:
+
+-   IPsec default settings that specify the following options:
+
+    1.  Exempt all ICMP traffic from IPsec.
+
+    2.  Key exchange (main mode) security methods and algorithm. We recommend that you use at least DH4, AES and SHA2 in your settings. Use the strongest algorithm combinations that are common to all your supported operating systems.
+
+    3.  Data protection (quick mode) algorithm combinations. Check **Require encryption for all connection security rules that use these settings**, and then specify one or more integrity and encryption combinations. We recommend that you don't include DES or MD5 in any setting. They're included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems.
+
+        If any NAT devices are present on your networks, use ESP encapsulation..
+
+    4.  Authentication methods. Include at least device-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then you must also include user-based Kerberos V5 authentication as an optional authentication method. Likewise, if any of your domain isolation members can't use Kerberos V5 authentication, then you must include certificate-based authentication as an optional authentication method.
+
+-   The following connection security rules:
+
+    -   A connection security rule that exempts all devices on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, if applicable in your environment.
+
+    -   A connection security rule, from any IP address to any, that requires inbound and requests outbound authentication using the default authentication specified earlier in this policy.
+
+        **Important**  
+        Be sure to begin operations by using request in and request out behavior until you're sure that all the devices in your IPsec environment are communicating successfully by using IPsec. After confirming that IPsec is operating as expected, you can change the GPO to require in, request out.
+
+         
+
+-   A registry policy that includes the following values:
+
+    -   Enable PMTU discovery. Enabling this setting allows TCP/IP to dynamically determine the largest packet size supported across a connection. The value is found at HKLM\\System\\CurrentControlSet\\Services\\TCPIP\\Parameters\\EnablePMTUDiscovery (dword). The sample GPO preferences XML file in [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) sets the value to **1**.
+
+    >**Note:**  For a sample template for these registry settings, see [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md).
+
+-   If domain member devices must communicate with devices in the encryption zone, ensure that you include in the isolated domain GPOs quick mode combinations that are compatible with the requirements of the encryption zone GPOs.
+
+**Next:** [Planning Server Isolation Zones](planning-server-isolation-zones.md)

windows/security/operating-system-security/network-security/windows-firewall/exempt-icmp-from-authentication.md

@@ -0,0 +1,24 @@
+---
+title: Exempt ICMP from Authentication 
+description: Learn how to add exemptions for any network traffic that uses the ICMP protocol in Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Exempt ICMP from Authentication
+
+
+This procedure shows you how to add exemptions for any network traffic that uses the ICMP protocol.
+
+**Administrative credentials**
+
+To complete this procedure, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
+
+To exempt ICMP network traffic from authentication
+
+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.  On the main Windows Defender Firewall with Advanced Security page, click **Windows Defender Firewall Properties**.
+
+3.  On the **IPsec settings** tab, change **Exempt ICMP from IPsec** to **Yes**, and then click **OK**.

windows/security/operating-system-security/network-security/windows-firewall/exemption-list.md

@@ -0,0 +1,46 @@
+---
+title: Exemption List 
+description: Learn about reasons to add devices to an exemption list in Windows Defender Firewall with Advanced Security and the trade-offs of having too many exemptions.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Exemption List
+
+
+When you implement a server and domain isolation security model in your organization, you're likely to find more challenges. Key infrastructure servers such as DNS servers and DHCP servers typically must be available to all devices on the internal network, yet secured from network attacks. However, if they must remain available to all devices on the network, not just to isolated domain members, then these servers can't require IPsec for inbound access, nor can they use IPsec transport mode for outbound traffic.
+
+In addition to the infrastructure servers mentioned earlier, there might also be other servers on the network that trusted devices can't use IPsec to access, which would be added to the exemption list.
+
+Generally, the following conditions are reasons to consider adding a device to the exemption list:
+
+-   If the device must be accessed by trusted devices but it doesn't have a compatible IPsec implementation.
+
+-   If the device must provide services to both trusted and untrusted devices, but doesn't meet the criteria for membership in the boundary zone.
+
+-   If the device must be accessed by trusted devices from different isolated domains that don't have an Active Directory trust relationship established with each other.
+
+-   If the device is a domain controller running version of Windows earlier than Windows Server 2008, or if any of its clients are running a version of Windows earlier than Windows Vista.
+
+-   If the device must support trusted and untrusted devices, but can't use IPsec to help secure communications to trusted devices.
+
+For large organizations, the list of exemptions might grow large if all the exemptions are implemented by one connection security rule for the whole domain or for all trusted forests. If you can require all devices in your isolated domain to run at least Windows Vista or Windows Server 2008, you can greatly reduce the size of this list. A large exemption list has several unwanted effects on every device that receives the GPO, including the following effects:
+
+-   Reduces the overall effectiveness of isolation.
+
+-   Creates a larger management burden (because of frequent updates).
+
+-   Increases the size of the IPsec policy, which means that it consumes more memory and CPU resources, slows down network throughput, and increases the time required to download and apply the GPO containing the IPsec policy.
+
+To keep the number of exemptions as small as possible, you have several options:
+
+-   Carefully consider the communications requirements of each isolation zone, especially server-only zones. They might not be required to communicate with every exemption in the domain-level policy for clients.
+
+-   Consolidate server functions. If several exempt services can be hosted at one IP address, the number of exemptions is reduced.
+
+-   Consolidate exempted hosts on the same subnet. Where network traffic volume allows, you might be able to locate the servers on a subnet that is exempted, instead of using exemptions for each IP address.
+
+As with defining the boundary zone, create a formal process to approve hosts being added to the exemption list. For a model of processing requests for exemptions, see the decision flowchart in the [Boundary Zone](boundary-zone.md) section.
+
+**Next:** [Isolated Domain](isolated-domain.md)

windows/security/operating-system-security/network-security/windows-firewall/filter-origin-documentation.md

@@ -0,0 +1,161 @@
+---
+title: Filter origin audit log improvements
+description: Filter origin documentation audit log improvements
+ms.prod: windows-client
+ms.topic: troubleshooting
+ms.date: 12/31/2017
+---
+
+# Filter origin audit log improvements
+
+Debugging packet drops is a continuous issue to Windows customers. In the past, customers had limited information about packet drops.
+
+Typically, when investigating packet drop events, a customer would use the field `Filter Run-Time ID` from Windows Filtering Platform (WFP) audits 5157 or 5152. 
+
+![Event properties.](images/event-properties-5157.png)
+
+The filter ID uniquely identifies the filter that caused the packet drop. The filter ID can be searched in the WFP state dump output to trace back to the Firewall rule where the filter originated from. 
+
+However, the filter ID isn't a reliable source for tracing back to the filter or the rule, as the filter ID can change for many reasons despite the rule not changing at all. This change in ID makes the diagnosis process error-prone and difficult.
+
+For customers to debug packet drop events correctly and efficiently, they would need more context about the blocking filter such as its origin.
+
+The blocking filters can be categorized under these filter origins:
+
+1. Firewall rules
+
+2. Firewall default block filters
+
+    a.    AppContainer loopback
+    
+    b.    Boottime default
+    
+    c.    Quarantine default
+    
+    d.    Query user default
+    
+    e.    Stealth
+    
+    f.    Universal Windows Platform (UWP) default
+    
+    g.    Windows Service Hardening (WSH) default
+
+The next section describes the improvements made to audits 5157 and 5152, and how the above filter origins are used in these events. These improvements were added in the Windows Server 2022 and Windows 11 releases.
+ 
+ ## Improved firewall audit 
+ 
+The two new fields added to the audit 5157 and 5152 events are `Filter Origin` and `Interface Index`.
+ 
+The `Filter Origin` field helps identify the cause of the drop. Packet drops from firewall are explicitly dropped by default block filters created by the Windows Firewall service or a firewall rule that may be created by users, policies, services, apps, etc.
+
+`Filter Origin` specifies either the rule ID (a unique identifier of a Firewall rule) or the name of one of the default block filters.
+
+The `Interface Index` field specifies the network interface in which the packet was dropped. This field helps to identify which interface was quarantined, if the `Filter Origin` is a `Quarantine Default`.
+
+To enable a specific audit event, run the corresponding command in an administrator command prompt:
+
+|**Audit #**|**Enable command**|**Link**|
+|:-----|:-----|:-----|
+|**5157**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable`|[5157(F): The Windows Filtering Platform has blocked a connection.](../../../threat-protection/auditing/event-5157.md)|
+|**5152**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable`|[5152(F): The Windows Filtering Platform blocked a packet.](../../../threat-protection/auditing/event-5152.md)|
+
+## Example flow of debugging packet drops with filter origin 
+
+As the audit surfaces `Filter Origin` and `Interface Index`, the network admin can determine the root cause of the network packet drop and the interface it happened on.
+
+![Event audit.](images/event-audit-5157.png)
+
+The next sections are divided by `Filter Origin` type, the value is either a rule name or the name of one of the default block filters. If the filter origin is one of the default block filters, skip to the section, **Firewall default block filters**. Otherwise, continue to the section **Firewall rules**.
+
+## Firewall rules
+
+Run the following PowerShell command to generate the rule information using `Filter Origin`. 
+
+```Powershell
+Get-NetFirewallRule -Name "<Filter Origin>"
+Get-NetFirewallRule -Name " {A549B7CF-0542-4B67-93F9-EEBCDD584377} "
+```
+
+![Firewall rule.](images/firewallrule.png)
+
+After identifying the rule that caused the drop, the network admin can now modify/disable the rule to allow the traffic they want through command prompt or using the Windows Defender UI. The network admin can find the rule in the UI with the rule's `DisplayName`.
+
+>[!NOTE]
+> Firewall rules from Mobile Device Management (MDM) store cannot be searched using the Windows Defender UI. Additionally, the above method will not work when the `Filter Origin` is one of the default block filters, as they do not correspond to any firewall rules.
+
+## Firewall default block filters
+
+**AppContainer loopback**
+
+Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn't enabled properly for the Universal Windows Platform (UWP) app.
+
+To enable localhost loopback in a local debugging environment, see [Communicating with localhost](/windows/iot-core/develop-your-app/loopback).
+
+To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged win32 app, see [uap4:LoopbackAccessRules](/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules).
+
+**Boottime default**
+
+Network drop events from the boottime default block filter origin occur when the computer is booting up and the firewall service isn't yet running. Services will need to create a boottime allow filter to allow the traffic. It should be noted that it's not possible to add boottime filters through firewall rules.
+
+**Quarantine default**
+
+Network drops from the quarantine default block filter occur when the interface is temporarily quarantined by Firewall service. The firewall service quarantines an interface when it detects a change on the network, and based on several other factors, the firewall service may put the interface in quarantine as a safeguard. When an interface is in quarantine, the quarantine default block filter will block any new non-loopback inbound connections. 
+
+Run the following PowerShell command to generate more information about the interface:
+
+```Powershell
+Get-NetIPInterface –InterfaceIndex <Interface Index>
+Get-NetIPInterface –InterfaceIndex 5
+```
+
+![Quarantine default block filter.](images/quarantine-default-block-filter.png)
+
+To learn more about the quarantine feature, see [Quarantine behavior](quarantine.md).
+
+>[!NOTE]
+> Quarantine-related packet drops are often transient and signify nothing more than a network change on the interface.
+
+**Query user default**
+
+Network packet drops from query user default block filters occur when there's no explicit rule created to allow an inbound connection for the packet. When an application binds to a socket but doesn't have a corresponding inbound rule to allow packets on that port, Windows generates a pop up for the user to allow or deny the app to receive packets on the available network categories. If the user clicks to deny the connection in this popup, subsequent inbound packets to the app will be dropped. To resolve the drops: 
+
+1. Create an inbound firewall rule to allow the packet for this application. This packet will allow the packet to bypass any query user default block filters.
+
+2. Delete any block query user rules that may have been auto generated by the firewall service.
+
+To generate a list of all the query user block rules, you can run the following PowerShell command:
+
+```Powershell
+Get-NetFirewallRule | Where {$_.Name -like "*Query User*"}
+```
+
+![Query user default block filter.](images/query-user-default-block-filters.png)
+
+The query user pop-up feature is enabled by default. 
+
+To disable the query user pop-up, you can run the following command in administrative command prompt:
+
+```Console
+Netsh set allprofiles inboundusernotification disable
+```
+Or in PowerShell:
+
+```Powershell
+Set-NetFirewallProfile -NotifyOnListen False
+```
+
+**Stealth**
+
+Network drops from stealth filters are typically made to prevent port scanning.
+
+To disable stealth-mode, see [Disable stealth mode in Windows](/troubleshoot/windows-server/networking/disable-stealth-mode).
+
+**UWP default**
+
+Network drops from Universal Windows Platform (UWP) default inbound/outbound block filters are often caused by the UWP app not being configured correctly (that is, the UWP app is missing the correct capability tokens or loopback isn't enabled) or the private range is configured incorrectly. 
+
+For more information on how to debug drops caused by UWP default block filters, see [Troubleshooting UWP App Connectivity Issues](./troubleshooting-uwp-firewall.md).
+
+**WSH default**
+
+Network drops from Windows Service Hardening (WSH) default filters indicate that there wasn't an explicit Windows Service Hardening allow rule to allow network traffic for the protected service. The service owner will need to configure allow rules for the service if the block isn't expected.

windows/security/operating-system-security/network-security/windows-firewall/firewall-gpos.md

@@ -0,0 +1,14 @@
+---
+title: Firewall GPOs 
+description: In this example, a Group Policy Object is linked to the domain container because the domain controllers aren't part of the isolated domain.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Firewall GPOs
+
+
+All the devices on Woodgrove Bank's network that run Windows are part of the isolated domain, except domain controllers. To configure firewall rules, the GPO described in this section is linked to the domain container in the Active Directory OU hierarchy, and then filtered by using security group filters and WMI filters.
+
+The GPO created for the example Woodgrove Bank scenario includes [GPO\_DOMISO\_Firewall](gpo-domiso-firewall.md).

windows/security/operating-system-security/network-security/windows-firewall/firewall-policy-design-example.md

@@ -0,0 +1,100 @@
+---
+title: Basic Firewall Policy Design Example 
+description: This example features a fictitious company and illustrates firewall policy design for Windows Defender Firewall with Advanced Security.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Basic Firewall Policy Design Example
+
+
+In this example, the fictitious company Woodgrove Bank is a financial services institution.
+
+Woodgrove Bank has an Active Directory domain that provides Group Policy-based management for all their Windows devices. The Active Directory domain controllers also host Domain Name System (DNS) for host name resolution. Separate devices host Windows Internet Name Service (WINS) for network basic input/output system (NetBIOS) name resolution. A set of devices that are running UNIX provide the Dynamic Host Configuration Protocol (DHCP) services for automatic IP addressing.
+
+Woodgrove Bank is in the process of migrating their devices from Windows Vista and Windows Server 2008 to Windows 10 and Windows Server 2016. A significant number of the devices at Woodgrove Bank continue to run Windows Vista and Windows Server 2008. Interoperability between the previous and newer operating systems must be maintained. Wherever possible, security features applied to the newer operating systems must also be applied to the previous operating systems.
+
+A key line-of-business program called WGBank consists of a client program running on most of the desktop devices in the organization. This program accesses several front-end server devices that run the server-side part of WGBank. These front-end servers only do the processing—they don't store the data. The data is stored in several back-end database devices that are running Microsoft SQL Server.
+
+## Design requirements
+
+The network administrators want to implement Windows Defender Firewall with Advanced Security throughout their organization to provide another security layer to their overall security strategy. They want to create firewall rules that allow their business programs to operate, while blocking network traffic that isn't wanted.
+
+The following illustration shows the traffic protection needs for this design example.
+
+![design example 1.](images/wfas-designexample1.gif)
+
+1.  The network infrastructure servers that are running services, such as Active Directory, DNS, DHCP, or WINS, can receive unsolicited inbound requests from network clients. The network clients can receive the responses from the infrastructure servers.
+
+2.  The WGBank front-end servers can receive unsolicited inbound traffic from the client devices and the WGBank partner servers. The WGBank client devices and partner servers can receive the response.
+
+3.  The WGBank front-end servers can send updated information to the client devices to support real-time display. The clients don't poll for this unsolicited traffic, but must be able to receive it.
+
+4.  The WGBank back-end servers can receive SQL query requests from the WGBank front-end servers. The WGBank front-end servers can receive the corresponding responses.
+
+5.  There's no direct communications between the client devices and the WGBank back-end devices.
+
+6.  There's no unsolicited traffic from the WGBank back-end devices to the WGBank front-end servers.
+
+7.  Company policy prohibits the use of peer-to-peer file transfer software. A recent review by the IT staff found that although the perimeter firewall does prevent most of the programs in this category from working, two programs are being used by staff members that don't require an outside server. Firewall rules must block the network traffic created by these programs.
+
+8.  The WGBank partner servers can receive inbound requests from partner devices through the Internet.
+
+Other traffic notes:
+
+-   Devices aren't to receive any unsolicited traffic from any computer other than allowed above.
+
+-   Other outbound network traffic from the client devices not identified in this example is permitted.
+
+## Design details
+
+
+Woodgrove Bank uses Active Directory groups and Group Policy Objects to deploy the firewall settings and rules to the devices on their network. They know that they must deploy policies to the following collections of devices:
+
+-   Client devices that run Windows 11, Windows 10, Windows 8, or Windows 7
+
+-   WGBank front-end servers that run Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 or Windows Server 2008 R2 (there are none in place yet, but their solution must support adding them)
+
+-   WGBank partner servers that run Windows Server 2008
+
+-   WGBank back-end SQL Server devices that run Windows Server 2008 (there are none in place yet, but their solution must support adding them)
+
+-   Infrastructure servers that run Windows Server 2008
+
+-   Active Directory domain controllers that run Windows Server 2008 R2 or Windows Server 2012
+
+-   DHCP servers that run the UNIX operating system
+
+After the Woodgrove Bank network administrators evaluated these sets of devices, and compared them to the Active Directory organizational unit (OU) structure, they determined that there wasn't a good one-to-one match between the OUs and the sets. Therefore the firewall GPOs won't be linked directly to OUs that hold the relevant devices. Instead, the GPOs are linked to the domain container in Active Directory, and then WMI and group filters are attached to the GPO to ensure that it's applied to the correct devices.
+
+Setting up groups as described here ensures that you don't have to know what operating system a computer is running before assigning it to a group. A combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs.
+
+The following groups were created by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, and all devices that run Windows were added to the correct groups:
+
+-   **CG\_FIREWALL\_ALLCOMPUTERS**. Add the predefined and system managed **Domain computers** group as a member of this group. All members of the FIREWALL\_ALLCOMPUTERS group receive an operating system-specific GPO with the common firewall rules applied to all devices.
+
+    The two device types (client and server) are distinguished by using a WMI filters to ensure that only the policy intended for devices that are running a client version of Windows can be applied to that computer. A similar WMI filter on the server GPO ensures that only devices that are running server versions of Windows can apply that GPO. Each of the GPOs also has security group filters to prevent members of the group FIREWALL\_NO\_DEFAULT from receiving either of these two GPOs.
+
+    -   Client devices receive a GPO that configures Windows Defender Firewall to enforce the default Windows Defender Firewall behavior (allow outbound, block unsolicited inbound). The client default GPO also includes the built-in firewall rule groups Core Networking and File and Printer Sharing. The Core Networking group is enabled for all profiles, whereas the File and Printer Sharing group is enabled for only the Domain and Private profiles. The GPO also includes inbound firewall rules to allow the WGBank front-end server dashboard update traffic, and rules to prevent company-prohibited programs from sending or receiving network traffic, both inbound and outbound.
+
+    -   Server devices receive a GPO that includes similar firewall configuration to the client computer GPO. The primary difference is that the rules are enabled for all profiles (not just domain and private). Also, the rules for WGBank dashboard update aren't included, because it's not needed on server devices.
+
+    All rules are scoped to allow network traffic only from devices on Woodgrove Bank's corporate network.
+
+-   **CG\_FIREWALL\_NO\_DEFAULT**. Members of this group don't receive the default firewall GPO. Devices are added to this group if there's a business requirement for it to be exempted from the default firewall behavior. The use of a group to represent the exceptions instead of the group members directly makes it easier to support the dynamic nature of the client computer population. A new computer joined to the domain is automatically given the appropriate default firewall GPO, unless it's a member of this group.
+
+-   **CG\_FIREWALL\_WGB\_FE**. This group contains the computer accounts for all the WGBank front-end server devices. Members of this group receive a GPO that configures Windows Defender Firewall with inbound firewall rules to allow unsolicited WGBank client traffic. Devices in this group also receive the default firewall GPO.
+
+-   **CG\_FIREWALL\_WGB\_SQL**. This group contains the computer accounts for all the WGBank back-end devices that run SQL Server. Members of this group receive a GPO that configures Windows Defender Firewall with inbound firewall rules to allow the SQL Server program to receive unsolicited queries only from the WGBank front-end servers. Devices in this group also receive the default firewall GPO.
+
+-   **CG\_FIREWALL\_BOUNDARY\_WGBANKFE**. This group contains the computer accounts for the servers that host Web services that can be accessed from the Internet. Members of this group receive a GPO that adds an inbound firewall rule to allow inbound HTTP and HTTPS network traffic from any address, including the Internet. Devices in this group also receive the default firewall GPO.
+
+-   **CG\_FIREWALL\_WINS**. This group contains the computer accounts for all the WINS server devices. Members of this group receive a GPO that configures Windows Defender Firewall with an inbound firewall rule to allow unsolicited inbound requests from WINS clients. Devices in this group also receive the default firewall GPO.
+
+-   **CG\_FIREWALL\_ADDC**. This group contains all the computer accounts for the Active Directory domain controller server devices. Members of this group receive a GPO that configures Windows Defender Firewall with inbound firewall rules to allow unsolicited Active Directory client and server-to-server traffic. Devices in this group also receive the default firewall GPO.
+
+In your own design, create a group for each computer role in your organization that requires different or more firewall rules. For example, file servers and print servers require more rules to allow the incoming network traffic for those functions. If a function is ordinarily performed on most devices on the network, you might consider adding devices performing those roles to the common default firewall GPO set, unless there's a security reason not to include it there.
+
+**Next:** [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md)
+

windows/security/operating-system-security/network-security/windows-firewall/firewall-settings-lost-on-upgrade.md

@@ -0,0 +1,32 @@
+---
+title: Troubleshooting Windows Firewall settings after a Windows upgrade
+description: Firewall settings lost on upgrade
+ms.prod: windows-client
+ms.topic: troubleshooting
+ms.date: 12/31/2017
+---
+
+# Troubleshooting Windows Firewall settings after a Windows upgrade
+
+Use this article to troubleshoot firewall settings that are turned off after upgrading to a new version of Windows.
+
+## Rule groups
+
+To help you organize your list, individual built-in firewall rules are categorized within a group. For example, the following rules form part of the Remote Desktop group.
+
+- Remote Desktop – Shadow (TCP-In)
+- Remote Desktop – User Mode (TCP-In)
+- Remote Desktop – User-Mode (UDP-In)
+
+Other group examples include **core networking**, **file and print sharing**, and **network discovery**. Grouping allows administrators to manage sets of similar rules by filtering on categories in the firewall interface (wf.msc). Do this filtering by right-clicking on either **Inbound** or **Outbound Rules** and selecting **Filter by Group**. Optionally, you can use PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch.
+
+```Powershell
+Get-NetFirewallRule -Group <groupName>
+```
+
+> [!NOTE] 
+> Microsoft recommends to enable or disable an entire group instead of individual rules.
+
+Microsoft recommends that you enable/disable all of the rules within a group instead of one or two individual rules. This recommendation is because groups aren't only used to organize rules and allow batch rule modification by type, but they also represent a 'unit' by which rule state is maintained across a Windows upgrade. Rule groups, as opposed to individual rules, are the unit by which the update process determines what should be enabled/disabled when the upgrade is complete.
+
+For example, the Remote Desktop group consists of three rules. To ensure that the rule set is properly migrated during an upgrade, all three rules must be enabled. If only one rule is enabled, the upgrade process will see that two of three rules are disabled and then disable the entire group to maintain a clean, out-of-the-box configuration. This scenario has the unintended consequence of breaking Remote Desktop Protocol (RDP) connectivity to the host.

windows/security/operating-system-security/network-security/windows-firewall/gathering-information-about-your-active-directory-deployment.md

@@ -0,0 +1,26 @@
+---
+title: Gathering Information about Your Active Directory Deployment 
+description: Learn about gathering Active Directory information, including domain layout, organizational unit architecture, and site topology, for your firewall deployment.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Gathering Information about Your Active Directory Deployment
+
+
+Active Directory is another important item about which you must gather information. You must understand the forest structure. This structure includes domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where devices are currently placed, their configuration, and the impact of changes to Active Directory that result from implementing Windows Defender Firewall with Advanced Security. Review the following list for information needed:
+
+-   **Names and number of forests**. The forest (not the domain) is the security boundary in an Active Directory implementation. You must understand the current Active Directory architecture to determine the most effective strategy for deploying your firewall and connection security rules using Group Policy. It also enables you to understand which devices can be isolated and how best to accomplish the required degree of isolation.
+
+-   **Names and number of domains**. Authentication in server and domain isolation uses the IKE negotiation process with the Kerberos V5 protocol. This protocol assumes that devices are domain members.
+
+-   **Number and types of trusts**. Trusts affect the logical boundaries of domain isolation and define whether IKE negotiation can occur between devices in different Active Directory domains.
+
+-   **Names and number of sites**. Site architecture is aligned with the network topology. Understanding how sites are defined in Active Directory will help provide insight into replication and other details. Site architecture can provide a better understanding of the current Active Directory deployment.
+
+-   **OU structure**. OUs are logical constructs and can therefore be molded to fit many different requirements and goals. The OU structure is an ideal place to examine how Group Policy is currently used and how the OUs are laid out. You don't have to redesign an already implemented OU structure in order to effectively deploy firewall and connection security policy, but an understanding of the structure helps you know what WMI or group filtering is required to apply each GPO to the correct devices.
+
+-   **Existing IPsec policy**. Because this project culminates in the implementation of IPsec policy, you must understand how the network currently uses IPsec (if at all). Windows Defender Firewall connection security rules for versions of Windows prior to Windows Vista and Windows Server 2008 aren't compatible with earlier versions of Windows. If you already have IPsec policies deployed to devices running Windows XP and Windows Server 2003 in your organization, you must ensure that the new IPsec policies you deploy enable devices using either the old or new IPsec policies to communicate with each other.
+
+**Next:** [Gathering Information about Your Devices](gathering-information-about-your-devices.md)

windows/security/operating-system-security/network-security/windows-firewall/gathering-information-about-your-current-network-infrastructure.md

@@ -0,0 +1,107 @@
+---
+title: Gathering Info about Your Network Infrastructure 
+description: Learn how to gather info about your network infrastructure so that you can effectively plan for Windows Defender Firewall with Advanced Security deployment.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Gathering Information about Your Current Network Infrastructure
+
+
+Perhaps the most important aspect of planning for Windows Defender Firewall with Advanced Security deployment is the network architecture, because IPsec is layered on the Internet Protocol itself. An incomplete or inaccurate understanding of the network can prevent any Windows Defender Firewall solution from being successful. Understanding subnet layout, IP addressing schemes, and traffic patterns are part of this effort, but accurately documenting the following components are important to completing the planning phase of this project:
+
+-   **Network segmentation**. This component includes IP addressing maps, showing how your routers separate each network segment. It includes information about how the routers are configured, and what security filters they impose on network traffic flowing through them.
+
+-   Network address translation (NAT). NAT is a means of separating network segments by using a device that maps all of the IP addresses on one side of the device to a single IP address accessible on the other side.
+
+-   Network infrastructure devices. These devices include the routers, switches, hubs, and other network equipment that makes communications between the devices on the network possible.
+
+-   **Current network traffic model.** This component includes the quantity and the characteristics of the network traffic flowing through your network.
+
+-   Intrusion Detection System (IDS) devices. You'll need to identify if you have any IDS devices on your network that might be negatively impacted by any encryption introduced in an Encryption Zone.
+
+The goal is to have enough information to be able to identify an asset by its network location, in addition to its physical location.
+
+Don't use a complex and poorly documented network as a starting point for the design, because it can leave too many unidentified areas that are likely to cause problems during implementation.
+
+This guidance helps obtain the most relevant information for planning Windows Defender Firewall implementation, but it doesn't try to address other issues, such as TCP/IP addressing or virtual local area network (VLAN) segmentation.
+
+## Network segmentation
+
+
+If your organization doesn't have its current network architecture documented and available for reference, such documentation should be obtained as soon as possible before you continue with the design and deployment. If the documented information isn't current or hasn't been validated recently, you have two options:
+
+-   Accept that the lack of accurate information can cause risk to the project.
+
+-   Undertake a discovery project, either through manual processes or with network analysis tools that can provide the information you need to document the current network topology.
+
+Although the required information can be presented in many different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, don't include too much information. If necessary, use multiple diagrams that show different layers of detail. Use a top-level diagram that illustrates the major sites that make up your organization's network, and then break out each site into a more detailed diagram that captures a deeper level of detail. Continue until you reach the individual IP subnet level, and so have the means to identify the network location of every device in your organization.
+
+During this process, you might discover some network applications and services that aren't compatible with IPsec. For example, IPsec breaks network-based prioritization and port/protocol-based traffic management. If traffic management or prioritization must be based on ports or protocol, the host itself must be able to perform any traffic management or prioritization.
+
+Other examples of incompatibility include:
+
+-   Cisco NetFlow on routers can't analyze packets between IPsec members based on protocol or port.
+
+-   Router-based Quality of Service (QoS) can't use ports or protocols to prioritize traffic. However, using firewall rules that specify IP addresses to prioritize traffic aren't affected by this limitation of QoS. For example, a rule that says "From anyone to anyone using port 80 prioritize" doesn't work, but a rule that says "From anyone to 10.0.1.10 prioritize" works.
+
+-   Weighted Fair Queuing and other flow-based router traffic priority methods might fail.
+
+-   Devices that don't support or allow IP protocol 50, the port that is used by Encapsulating Security Payload (ESP).
+
+-   Router access control lists (ACLs) can't examine protocol and port fields in ESP-encrypted packets, and therefore the packets are dropped. ACLs based only on IP address are forwarded as usual. If the device can't parse ESP, any ACLs that specify port or protocol rules won't be processed on the ESP packets. If the device has an ESP parser and uses encryption, ACLs that specify port or protocol rules won't be processed on the ESP packets.
+
+-   Network monitoring tools might be unable to parse ESP packets that aren't encrypted (ESP-Null).
+
+    >**Note:**  Microsoft Message Analyzer can help in troubleshooting of unencrypted IPsec packets. The latest version of Message Analyzer is available on the [Microsoft Download Center](/message-analyzer/microsoft-message-analyzer-operating-guide).
+     
+## Network address translation (NAT)
+
+IPsec NAT traversal (NAT-T) enables IPsec peers that are behind NATs to detect the presence of NATs, negotiate IPsec security associations (SAs), and send ESP-protected data even though the addresses in the IPsec-protected IPv4 packets change. IPsec NAT-T doesn't support the use of AH across NAT devices.
+
+## Network infrastructure devices
+
+The devices that make up the network infrastructure (routers, switches, load balancers, and firewalls) must be able communicate using IPsec after the solution is implemented. For this reason, you have to examine the following characteristics of these network devices to ensure that they can handle the technical and physical requirements of the design:
+
+-   **Make/model**. You can use this information to determine the features that the device supports. In addition, check the BIOS version or software running on the device to ensure that IPsec is supported.
+
+-   **Amount of RAM**. This information is useful when you're analyzing capacity or the impact of IPsec on the device.
+
+-   **Traffic analysis**. Information, such as peak usage and daily or weekly trends, is helpful to have. The information helps provide a baseline snapshot of the device and how it's used over time. If problems occur after IPsec is implemented, the information can help determine whether the root cause is related to greater usage of the device.
+
+-   **Router ACLs that affect IPsec directly**. ACLs directly affect the ability of specific protocols to function. For example, blocking the Kerberos V5 protocol (UDP and TCP port 88) or IP protocol 50 or 51 prevents IPsec from working. Devices must also be configured to allow IKE traffic (UDP port 500) if using NAT-T (UDP port 4500).
+
+-   **Networks/subnets connected to device interfaces**. This information provides the best picture of what the internal network looks like. Defining the boundary of subnets based on an address range is straightforward and helps identify whether other addresses are either unmanaged or foreign to the internal network (such as IP addresses on the Internet).
+
+-   **VLAN segmentation**. Determining how VLANs are implemented on the network can help you understand traffic patterns and security requirements, and then help to determine how IPsec might augment or interfere with these requirements.
+
+-   **The maximum transmission unit (MTU) size on device interface(s)**. The MTU defines the largest datagram that can be transmitted on a particular interface without being divided into smaller pieces for transmission (a process also known as *fragmentation*). In IPsec communications, the MTU is necessary to anticipate when fragmentation occurs. Packet fragmentation must be tracked for Internet Security Association and Key Management Protocol (ISAKMP) by the router. IPsec configures the MTU size on the session to the minimum-discovered MTU size along the communication path being used, and then set the Don't Fragment bit (DF bit) to 1.
+
+    >**Note:**  If Path MTU (PMTU) discovery is enabled and functioning correctly, you do not have to gather the MTU size on device interfaces. Although sources, such as the Windows Server 2003 Hardening Guide, recommend disabling PMTU discovery, it must be enabled for IPsec to function correctly.
+
+-   **Intrusion detection system (IDS) in use**. Your IDS must have an IPsec-compatible parser to detect ESP packets. If the IDS doesn't have such a parser, it can't determine if data in those packets is encrypted.
+
+After you obtain this information, you can quickly determine whether you must upgrade the devices to support the requirements of the project, change the ACLs, or take other measures to ensure that the devices can handle the loads needed.
+
+## Current network traffic model
+
+After you gather the addressing and network infrastructure information, the next step is to examine the communications flow. For example, if a department such as Human Resources (HR) spans several buildings, and you want to use server isolation with encryption to help protect information in that department, you must know how those buildings are connected to determine the level of "trust" to place in the connection. A highly secured building that is connected by an unprotected cable to another building that isn't secured can be compromised by an eavesdropping or information replay attack. If such an attack is considered a threat, IPsec can help by providing strong mutual authentication and traffic encryption for trusted hosts. IPsec allows you to more securely communicate across untrusted links such as the Internet.
+
+When you examine traffic flow, look closely at how all managed and unmanaged devices interact. These devices include non-Windows-based devices running Linux, UNIX, and Macintosh. Ask yourself such questions as:
+
+-   Do specific communications occur at the port and protocol level, or are there many sessions between the same hosts across many protocols?
+
+-   How do servers and clients communicate with each other?
+
+-   Are there security devices or projects currently implemented or planned that could affect an isolation deployment? For example, if you use Windows Defender Firewall on your devices to "lock down" specific ports, such as UDP 500, IKE negotiations fail.
+
+Some of the more common applications and protocols are as follows:
+
+-   **NetBIOS over TCP/IP (NetBT) and server message block (SMB)**. On a LAN, it's common to have ports 137, 138, and 139 enabled for NetBT and port 445 enabled for SMB. These ports provide NetBIOS name resolution services and other features. Unfortunately, they also allow the creation of *null sessions*. A null session is a session that is established on a host that doesn't use the security context of a known user or entity. Frequently, these sessions are anonymous.
+
+-   **Remote procedure call (RPC)**. RPC operates by listening on a port known as the *endpoint mapper*, TCP port 135. The response to a query on this port is an instruction to begin communication on another port in the ephemeral range (ports numbered over 1024). In a network that is segmented by firewalls, RPC communication presents a configuration challenge because it means to open the RPC listener port, and all ports greater than 1024. Opening so many ports increases the attack surface of the whole network and reduces the effectiveness of the firewalls. Because many applications depend on RPC for basic functionality, any firewall and connection security policy must take RPC requirements into account.
+
+-   **Other traffic**. Windows Defender Firewall can help secure transmissions between devices by providing authentication of the packets in addition to encrypting the data that they contain. The important thing to do is to identify what must be protected, and the threats that must be mitigated. Examine and model other traffic or traffic types that must be secured.
+
+**Next:** [Gathering Information about Your Active Directory Deployment](gathering-information-about-your-active-directory-deployment.md)

windows/security/operating-system-security/network-security/windows-firewall/gathering-information-about-your-devices.md

@@ -0,0 +1,48 @@
+---
+title: Gathering Information about Your Devices 
+description: Learn what information to gather about the devices in your enterprise to plan your Windows Defender Firewall with Advanced Security deployment.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Gathering Information about Your Devices
+
+
+One of the most valuable benefits of conducting an asset discovery project is the large amount of data that is obtained about the client and server devices on the network. When you start designing and planning your isolation zones, you must make decisions that require accurate information about the state of all hosts to ensure that they can use IPsec as planned.
+
+Capture the following information from each device:
+
+-   **Computer name**. This name is the device's NetBIOS or DNS name that identifies the device on the network. Because a device can have more than one media access control (MAC) or IP address, the device's name is one of the criteria that can be used to determine uniqueness on the network. Because device names can be duplicated under some circumstances, the uniqueness shouldn't be considered absolute.
+
+-   **IP address for each network adapter**. The IP address is the address that is used with the subnet mask to identify a host on the network. An IP address isn't an effective way to identify an asset because it's often subject to change.
+
+-   **Operating system, service pack, and hotfix versions**. The operating system version is a key factor in determining the ability of a host to communicate by using IPsec. It's also important to track the current state of service packs and updates that might be installed, because these packs and updates are often used to determine that minimum security standards have been met.
+
+-   **Domain membership**. This information is used to determine whether a device can obtain IPsec policy from Active Directory or whether it must use a local IPsec policy.
+
+-   **Physical location**. This information is just the location of the device in your organization. It can be used to determine whether a device can participate in a specific isolation group based on its location or the location of the devices that it communicates with regularly.
+
+-   **Hardware type or role**. Some tools that perform host discovery can provide this information by querying the hardware information and running applications to determine its type, such as server, workstation, or portable device. You can use this information to determine the appropriate IPsec policy to assign, whether a specific device can participate in isolation, and in which isolation group to include the device.
+
+After collecting all this information and consolidating it into a database, perform regular discovery efforts periodically to keep the information current. You need the most complete and up-to-date picture of the managed hosts on their networks to create a design that matches your organization's requirements.
+
+You can use various methods to gather data from the hosts on the network. These methods range from high-end, fully automated systems to manual data collection. Generally, the use of automated methods to gather data is preferred over manual methods for reasons of speed and accuracy.
+
+## Automated Discovery
+
+Using an automated auditing network management system provides valuable information about the current state of the IT infrastructure.
+
+
+## Manual Discovery
+
+
+The biggest difference between manual discovery methods and automated methods is time.
+
+You can use Windows PowerShell to create a script file that can collect the system configuration information. For more information, see [Windows PowerShell Scripting](https://go.microsoft.com/fwlink/?linkid=110413).
+
+Whether you use an automatic, manual, or hybrid option to gather the information, one of the biggest issues that can cause problems to the design is capturing the changes between the original inventory scan and the point at which the implementation is ready to start. After the first scan has been completed, make support staff aware that all other changes must be recorded and the updates noted in the inventory.
+
+This inventory will be critical for planning and implementing your Windows Defender Firewall design.
+
+**Next:** [Gathering Other Relevant Information](gathering-other-relevant-information.md)

windows/security/operating-system-security/network-security/windows-firewall/gathering-other-relevant-information.md

@@ -0,0 +1,69 @@
+---
+title: Gathering Other Relevant Information 
+description: Learn about additional information you may need to gather to deploy Windows Defender Firewall with Advanced Security policies in your organization.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Gathering Other Relevant Information
+
+
+This topic discusses several other things that you should examine to see whether they'll cause any complications in your ability to deploy Windows Defender Firewall with Advanced Security policies in your organization.
+
+## Capacity considerations
+
+Because IPsec uses mathematically intensive cryptographic techniques, it can consume significant overhead on a device. Areas to watch:
+
+-   **Encryption.** You might use 256-bit Advanced Encryption Standard (AES-256) and 384-bit Secure Hash Algorithm (SHA-384) to check integrity in situations that require the strongest available encryption and key exchange protection. If you have NICs that support IPsec Task Offload, you can reduce the effect that encryption has on network throughput. For more information, see [IPsec Task Offload](/previous-versions/windows/it-pro/windows-server-2003/cc776369(v=ws.10)).
+
+-   **Security association (SA) negotiation.** You can use a shorter lifetime for the main mode SA, such as three hours, but then you might need to make tradeoffs. Because each main mode SA occupies approximately 5  KB of RAM, situations in which a server brokers tens of thousands of concurrent connections can lead to overutilization.
+
+-   **NAT devices.** As discussed earlier, NAT doesn't allow Authentication Header (AH) conversations between hosts. If NAT devices exist on the internal network, ESP must be selected instead of AH.
+
+-   **Switches and routers.** Proper capacity planning for the implementation of IPsec is more about thorough testing and expected traffic loads than exact calculations. You might have to upgrade or reconfigure switches or routers that currently exceed 75 percent usage to allow for increased traffic on the device and still provide some extra usage for bursts of traffic.
+
+-   **Other factors.** These include CPU usage on network infrastructure servers, increased overhead on servers and workstations running IPsec (especially servers, because they usually contain more main mode SAs than clients), and increased network latency because of IPsec negotiation.
+
+    >**Note:**  When Microsoft deployed its own domain isolation solution, it found a one to three percent increase in usage on the network as a direct result of IPsec.
+
+## Group Policy deployment groups and WMI filters
+
+You don't have to rearrange the organization unit (OU) hierarchy of your Active Directory domains to effectively deploy Windows Defender Firewall GPOs. Instead, you can link your GPOs at the domain level (or another high level container), and then use security group filtering or WMI filtering to ensure that only the appropriate devices or users can apply the GPO settings. We recommend that you use WMI filtering to dynamically ensure that GPOs apply only to devices that are running the correct operating system. It's not necessary to use this technique if your network consists of devices.
+
+## Different Active Directory trust environments
+
+When you design a domain isolation policy, consider any logical boundaries that might affect IPsec-secured communications. For example, the trust relationships between your domains and forests are critical in determining an appropriate IKE authentication method.
+
+Kerberos V5 authentication is recommended for use in a two-way (mutual) domain and forest trust environment. You can use Kerberos V5 for IKE authentication across domains that have two-way trusts established, if the domains are in the same forest or different forests. If the two domains are in different forests, you must configure two external trusts, one for each direction, between the domains. The external trusts must use the fully qualified domain name (FQDN) of the domains, and IPsec policy must allow an IKE initiator in one domain to communicate with any domain controller in the forest domain hierarchy, so that the initiator can obtain a Kerberos V5 ticket from a domain controller in the responder’s domain. If firewalls separate the domains, then you must configure the firewall to allow Kerberos V5 traffic over UDP destination port 88, TCP destination port 88, and UDP destination port 389.
+
+If the use of Kerberos V5 authentication isn't possible because two-way trusts across forests can't be established as in some large enterprise environments, you can use a public key infrastructure (PKI) and digital certificates to establish IPsec-trusted communication.
+
+## Creating firewall rules to permit IKE, AH, and ESP traffic
+
+
+In some cases, IPsec-secured traffic might have to pass through a router, perimeter firewall, or other filtering device. If there's a router, unless the router filters TCP and UDP traffic or other upper-level protocol headers, no special configuration is required to allow the IPsec traffic to be forwarded.
+
+If there's a filtering router or a firewall, you must configure these devices to allow IPsec traffic to be forwarded. Configure the firewall to allow IPsec traffic on UDP source and destination port 500 (IKE), UDP source and destination port 4500 (IPsec NAT-T), and IP Protocol 50 (ESP). You might also have to configure the firewall to allow IPsec traffic on IP protocol 51 (AH) to allow troubleshooting by IPsec administrators and to allow the IPsec traffic to be inspected.
+
+## Network load balancing and server clusters
+
+There are challenges implementing connection security for network traffic going to and from network load balancing (NLB) clusters and server clusters. NLB enables multiple servers to be clustered together to provide high availability for a service by providing automatic failover to other nodes in the cluster. Because IPsec matches a security association to a specific device, it prevents different devices from handling the same client connection. If a different node in the cluster responds to an IPsec connection that was originally established by another node, the traffic will be dropped by the client device as untrusted.
+
+This dropping of traffic means that NLB in "no affinity" mode isn't supported by IPsec at all. If you must use "no affinity" mode in the cluster, then consider including the servers that make up the cluster in your IPsec exemption group, and allowing clients to communicate with the servers without IPsec.
+
+When a TCP connection is dropped because of a cluster node failover, IPsec detects the TCP connection failure and removes the IPsec SAs for that connection. When the new TCP connection is established to another node, IPsec can negotiate new SAs immediately without having to wait for the obsolete SAs to time out.
+
+## Network inspection technologies
+
+Within a TCP/IP packet, IPsec without encryption changes the offsets for the destination ports and protocols. These changes can adversely affect applications that are running on network devices such as routers that monitor and manage traffic on the network. While some network applications have been updated to support IPsec, some aren't yet compatible. Check with the vendor of your device to see whether the changes in the protocol and port fields caused by IPsec are compatible with the device.
+
+Any device designed to view network traffic, such as hardware protocol analyzers or Microsoft Network Monitor, can't parse ESP-encrypted traffic. Only the destination device, with which the originating device negotiated the connection, can decrypt the traffic.
+
+In general, IPsec defeats network-based prioritization and port- or protocol-based traffic management. For encrypted packets, there's no workaround; the host itself must handle any traffic management functions. For unencrypted, authenticated-only packets, the devices and applications must be aware of how IPsec changes packets to be able to do anything with them other than route them to the correct host. If you can't upgrade monitoring or management devices to support IPsec, it's important that you record this information and figure it into your domain or server isolation design.
+
+Network Monitor includes parsers for the ISAKMP (IKE), AH, and ESP protocols. Network Monitor parsers for ESP can parse inside the ESP packet only if ESP null-encryption is being used. Network Monitor can't parse the encrypted parts of IPsec ESP traffic when encryption is performed in software. However, if encryption is performed by an IPsec hardware offload network adapter, the ESP packets can be decrypted when Network Monitor captures them on either the source or the destination and, therefore, they can be parsed. To diagnose ESP software-encrypted communication, you must disable ESP encryption and use ESP-null encryption by changing the IPsec policy or connection security rule on both devices.
+
+Message Analyzer is available on the [Microsoft Download Center](/message-analyzer/microsoft-message-analyzer-operating-guide).
+
+**Next:** [Determining the Trusted State of Your Devices](determining-the-trusted-state-of-your-devices.md)

windows/security/operating-system-security/network-security/windows-firewall/gathering-the-information-you-need.md

@@ -0,0 +1,22 @@
+---
+title: Gathering the Information You Need 
+description: Collect and analyze information about your network, directory services, and devices to prepare for Windows Defender Firewall with Advanced Security deployment.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Gathering the Information You Need
+
+
+Before starting the planning process for a Windows Defender Firewall with Advanced Security deployment, you must collect and analyze up-to-date information about the network, the directory services, and the devices that are already deployed in the organization. This information enables you to create a design that accounts for all possible elements of the existing infrastructure. If the gathered information isn't accurate, problems can occur when devices and devices that weren't considered during the planning phase are encountered during implementation.
+
+Review each of the following articles for guidance about the kinds of information that you must gather:
+
+-   [Gathering Information about Your Conversational Network Infrastructure](gathering-information-about-your-current-network-infrastructure.md)
+
+-   [Gathering Information about Your Active Directory Deployment](gathering-information-about-your-active-directory-deployment.md)
+
+-   [Gathering Information about Your Devices](gathering-information-about-your-devices.md)
+
+-   [Gathering Other Relevant Information](gathering-other-relevant-information.md)

windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-boundary.md

@@ -0,0 +1,37 @@
+---
+title: GPO\_DOMISO\_Boundary 
+description: This example GPO supports devices that aren't part of the isolated domain to access specific servers that must be available to those untrusted devices.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# GPO\_DOMISO\_Boundary
+
+
+This GPO is authored by using the Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools. Woodgrove Bank began by copying and pasting the GPO for the Windows Server 2008 version of the isolated domain GPO, and then renamed the copy to reflect its new purpose.
+
+This GPO supports the ability for devices that aren't part of the isolated domain to access specific servers that must be available to those untrusted devices. It's intended to only apply to server devices that are running at least Windows Server 2008.
+
+## IPsec settings
+
+The copied GPO includes and continues to use the IPsec settings that configure key exchange, main mode, and quick mode algorithms for the isolated domain when authentication can be used.
+
+## Connection security rules
+
+
+Rename the **Isolated Domain Rule** to **Boundary Zone Rule**. Change the authentication mode to **Request inbound and request outbound**. In this mode, the device uses authentication when it can, such as during communication with a member of the isolated domain. It also supports the "fall back to clear" ability of request mode when an untrusted device that isn't part of the isolated domain connects.
+
+## Registry settings
+
+
+The boundary zone uses the same registry settings as the isolated domain to optimize IPsec operation. For more information, see the description of the registry settings in [Isolated Domain](isolated-domain.md).
+
+## Firewall rules
+
+
+Copy the firewall rules for the boundary zone from the GPO that contains the firewall rules for the isolated domain. Customize this copy, removing rules for services not needed on servers in this zone, and adding inbound rules to allow the network traffic for the services that are to be accessed by other devices. For example, Woodgrove Bank added a firewall rule to allow inbound network traffic to TCP port 80 for Web client requests.
+
+Make sure that the GPO that contains firewall rules for the isolated domain doesn't also apply to the boundary zone to prevent overlapping, and possibly conflicting rules.
+
+**Next:** [Encryption Zone GPOs](encryption-zone-gpos.md)

windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-encryption.md

@@ -0,0 +1,51 @@
+---
+title: GPO\_DOMISO\_Encryption\_WS2008 
+description: This example GPO supports the ability for servers that contain sensitive data to require encryption for all connection requests.
+ms.topic: conceptual
+ms.prod: windows-client
+ms.date: 09/08/2021
+---
+
+# GPO\_DOMISO\_Encryption\_WS2008
+
+
+This GPO is authored by using the Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools. Woodgrove Bank began by copying and pasting the GPO for the Windows Server 2008 version of the isolated domain GPO, and then renamed the copy to reflect its new purpose.
+
+This GPO supports the ability for servers that contain sensitive data to require encryption for all connection requests. It's intended to only apply to server computers that are running Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008.
+
+## IPsec settings
+
+
+The copied GPO includes and continues to use the IPsec settings that configure key exchange, main mode, and quick mode algorithms for the isolated domain. The following changes are made to encryption zone copy of the GPO:
+
+The encryption zone servers require all connections to be encrypted. To do this encryption, change the IPsec default settings for the GPO to enable the setting **Require encryption for all connection security rules that use these settings**. This setting disables all integrity-only algorithm combinations.
+
+## Connection security rules
+
+
+Rename the **Isolated Domain Rule** to **Encryption Zone Rule**. Leave the authentication mode setting on **Require inbound and request outbound**. In this mode, the computer forces authentication for all inbound network traffic, and uses it when it can on outbound traffic.
+
+## Registry settings
+
+
+The encryption zone uses the same registry settings as the isolated domain to optimize IPsec operation. For more information, see the description of the registry settings in [Isolated Domain](isolated-domain.md).
+
+## Firewall rules
+
+
+Copy the firewall rules for the encryption zone from the GPO that contains the firewall rules for the isolated domain. Customize this copy, removing rules for services not needed on servers in this zone, and adding inbound rules to allow the network traffic for the services that are to be accessed by other computers. For example, Woodgrove Bank added a firewall rule to allow inbound network traffic to TCP port 1433 for SQL Server client requests.
+
+Change the action for every inbound firewall rule from **Allow the connection** to **Allow only secure connections**, and then select **Require the connections to be encrypted**.
+
+Make sure that the GPO that contains firewall rules for the isolated domain doesn't also apply to the boundary zone to prevent overlapping, and possibly conflicting rules.
+
+**Next:** [Server Isolation GPOs](server-isolation-gpos.md)
+
+ 
+
+ 
+
+
+
+
+

windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-firewall.md

@@ -0,0 +1,59 @@
+---
+title: GPO\_DOMISO\_Firewall 
+description: Learn about the settings and rules in this example GPO, which is authored by using the Group Policy editing tools.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# GPO\_DOMISO\_Firewall
+
+
+This GPO is authored by using the Windows Defender Firewall 
+with Advanced Security interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It is intended to only apply to devices that are running at least Windows 7 or Windows Server 2008.
+
+## Firewall settings
+
+This GPO provides the following settings:
+
+-   Unless otherwise stated, the firewall rules and settings described here are applied to all profiles.
+
+-   The firewall is enabled, with inbound, unsolicited connections blocked and outbound connections allowed.
+
+-   Under the domain profile, the settings **Display notifications to the user**, **Apply local firewall rules**, and **Apply local connection security rules** are all set to **No**. These settings are applied only to the domain profile because the devices can only receive an exception rule for a required program from a GPO if they are connected to the domain. Under the public and private profiles, those settings are all set to **Yes**.
+
+    >**Note:**  Enforcing these settings requires that you define any firewall exceptions for programs, because the user cannot manually permit a new program. You must deploy the exception rules by adding them to this GPO. We recommend that you do not enable these settings until you have tested all your applications and have tested the resulting rules in a test lab and then on pilot devices.
+
+## Firewall rules
+
+This GPO provides the following rules:
+
+-   Built-in firewall rule groups are configured to support typically required network operation. The following rule groups are set to **Allow the connection**:
+
+    -   Core Networking
+
+    -   File and Printer Sharing
+
+    -   Network Discovery
+
+    -   Remote Administration
+
+    -   Remote Desktop
+
+    -   Remote Event Log Management
+
+    -   Remote Scheduled Tasks Management
+
+    -   Remote Service Management
+
+    -   Remote Volume Management
+
+    -   Windows Defender Firewall Remote Management
+
+    -   Windows Management Instrumentation (WMI)
+
+    -   Windows Remote Management
+
+-   A firewall exception rule to allow required network traffic for the WGBank dashboard program. This inbound rule allows network traffic for the program Dashboard.exe in the %ProgramFiles%\\WGBank folder. The rule is also filtered to only allow traffic on port 1551. This rule is applied only to the domain profile.
+
+**Next:** [Isolated Domain GPOs](isolated-domain-gpos.md)

windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-isolateddomain-clients.md

@@ -0,0 +1,77 @@
+---
+title: GPO\_DOMISO\_IsolatedDomain\_Clients 
+description: Author this GPO by using Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# GPO\_DOMISO\_IsolatedDomain\_Clients
+
+
+This GPO is authored by using the Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It's intended to only apply to client devices that are running Windows 8, Windows 7, or Windows Vista.
+
+Because client devices can sometimes be portable, the settings and rules for this GPO are applied to only the domain profile.
+
+## General settings
+
+This GPO provides the following settings:
+
+-   No firewall settings are included in this GPO. Woodgrove Bank created separate GPOs for firewall settings (see the [Firewall GPOs](firewall-gpos.md) section) in order to share them with all clients in all isolation zones with minimum redundancy.
+
+-   The ICMP protocol is exempted from authentication requirements to support easier network troubleshooting.
+
+-   Diffie-Hellman Group 2 is specified as the key exchange algorithm. This algorithm is the strongest algorithm available that is supported by all the operating systems that are being used at Woodgrove Bank. After Woodgrove Bank has completed the upgrade to versions of Windows that support stronger algorithms, they can remove the weaker key exchange algorithms, and use only the stronger ones.
+
+-   The registry settings shown in the following table. For more information, see the description of the registry settings in [Isolated Domain](isolated-domain.md).
+
+| Setting | Value |
+| - | - |
+| Enable PMTU Discovery | 1 |
+| IPsec Exemptions | 3 |
+
+-   The main mode security method combinations in the order shown in the following table.
+
+| Integrity | Encryption |
+| - | - |
+| Secure Hash Algorithm (SHA-1) | Advanced Encryption Standard (AES-128) | 
+| SHA-1 | 3DES |
+    
+-   The following quick mode security data integrity algorithms combinations in the order shown in the following table.
+
+| Protocol | Integrity | Key Lifetime (minutes/KB) |
+| - | - | - |
+| ESP | SHA-1 | 60/100,000 |
+
+-   The quick mode security data integrity and encryption algorithm combinations in the order shown in the following table.
+
+| Protocol | Integrity | Encryption | Key Lifetime (minutes/KB) |
+| - | - | - | - |
+| ESP | SHA-1 | AES-128 | 60/100,000| 
+| ESP | SHA-1 | 3DES | 60/100,000| 
+
+>**Note:**  Do not use the MD5 and DES algorithms in your GPOs. They are included only for compatibility with previous versions of Windows.
+
+## Connection Security Rules
+
+This GPO provides the following rules:
+
+-   A connection security rule named **Isolated Domain Rule** with the following settings:
+
+    -   From **Any IP address** to **Any IP address**.
+
+    -   **Require inbound and request outbound** authentication requirements.
+
+        >**Important:**  On this, and all other GPOs that require authentication, Woodgrove Bank first chose to only request authentication. After confirming that the devices were successfully communicating by using IPsec, they switched the GPOs to require authentication.
+
+    -   For **First authentication methods**, select **Computer Kerberos v5** as the primary method. Add certificate-based authentication from **DC=com,DC=woodgrovebank,CN=CorporateCertServer** for devices that can't run Windows or can't join the domain, but must still participate in the isolated domain.
+
+    -   For **Second authentication**, select **User Kerberos v5**, and then select the **Second authentication is optional** check box.
+
+-   A connection security rule to exempt devices that are in the exemption list from the requirement to authenticate:
+
+    -   The IP addresses of all devices on the exemption list must be added individually under **Endpoint 2**.
+
+    -   Authentication mode is set to **Do not authenticate**.
+
+**Next:** [GPO\_DOMISO\_IsolatedDomain\_Servers](gpo-domiso-isolateddomain-servers.md)

windows/security/operating-system-security/network-security/windows-firewall/gpo-domiso-isolateddomain-servers.md

@@ -0,0 +1,20 @@
+---
+title: GPO\_DOMISO\_IsolatedDomain\_Servers 
+description: Author this GPO by using the Windows Defender Firewall with Advanced Security interface in the Group Policy editing tools.
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# GPO\_DOMISO\_IsolatedDomain\_Servers
+
+
+This GPO is authored by using the Windows Defender Firewall interface in the Group Policy editing tools. The User Configuration section of the GPO is disabled. It's intended to only apply to server devices that are running at least Windows Server 2008.
+
+Because so many of the settings and rules for this GPO are common to those settings and rules in the GPO for at least Windows Vista, you can save time by exporting the Windows Defender Firewall piece of the GPO for at least Windows Vista, and importing it to the GPO for at least Windows Server 2008. After the import, change only the items specified here:
+
+-   This GPO applies all its settings to all profiles: Domain, Private, and Public. Because a server isn't expected to be mobile and changing networks, configuring the GPO in this way prevents a network failure or the addition of a new network adapter from unintentionally switching the device to the Public profile with a different set of rules (the example of a server running Windows Server 2008).
+
+    >**Important:**  Windows Vista and Windows Server 2008 support only one network location profile at a time. The profile for the least secure network type is applied to the device. If you attach a network adapter to a device that is not physically connected to a network, the public network location type is associated with the network adapter and applied to the device.
+
+**Next:** [Boundary Zone GPOs](boundary-zone-gpos.md)

windows/security/operating-system-security/network-security/windows-firewall/identifying-your-windows-firewall-with-advanced-security-deployment-goals.md

@@ -0,0 +1,24 @@
+---
+title: Identify implementation goals for Windows Defender Firewall with Advanced Security Deployment 
+description: Identifying Your Windows Defender Firewall with Advanced Security (WFAS) implementation goals
+ms.prod: windows-client
+ms.topic: conceptual
+ms.date: 09/08/2021
+---
+
+# Identifying Windows Defender Firewall with Advanced Security implementation goals 
+
+Correctly identifying your Windows Defender Firewall with Advanced Security implementation goals is essential for the success of your Windows Defender Firewall design project. Form a project team that can clearly articulate deployment issues in a vision statement. When you write your vision statement, identify, clarify, and refine your implementation goals. Prioritize and, if possible, combine your implementation goals so that you can design and deploy Windows Defender Firewall by using an iterative approach. You can take advantage of the predefined Windows Defender Firewall implementation goals presented in this guide that are relevant to your scenarios.
+
+The following table lists the three main tasks for articulating, refining, and later documenting your Windows Defender Firewall implementation goals:
+
+
+|                                                                                            Deployment goal tasks                                                                                             |                                                                                                                                                                                                                                                                  Reference links                                                                                                                                                                                                                                                                   |
+|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Evaluate predefined Windows Defender Firewall with Advanced Security implementation goals that are provided in this section of the guide, and combine one or more goals to reach your organizational objectives. | Predefined implementation goals:  <p><ul><li>[Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)</li><p><li>[Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)</li> <p><li>[Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)</li> <p><li>[Restrict Access to Sensitive Resources to Only Specified Users or Devices](restrict-access-to-only-specified-users-or-devices.md)</li></ul> |
+|                                   Map one goal or a combination of the predefined implementation goals to an existing Windows Defender Firewall with Advanced Security design.                                   |                                                                                                                                                                        <ul><li>[Mapping Your implementation goals to a Windows Defender Firewall with Advanced Security Design](mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md)</li></ul>                                                                                                                                                                        |
+|                 Based on the status of your current infrastructure, document your implementation goals for your Windows Defender Firewall with Advanced Security design into a deployment plan.                  |                                                                                                                              <ul><li>[Designing A Windows Defender Firewall Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)</li> <p><li>[Planning Your Windows Defender Firewall Design with Advanced Security](planning-your-windows-firewall-with-advanced-security-design.md)</li></ul>                                                                                                                              |
+
+<br />
+
+**Next:** [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)