mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 02:43:43 +00:00
updating for Windows 10
This commit is contained in:
Brian Lich
@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Gathering Information about Your Devices (Windows 10)
|
||||
description: Gathering Information about Your Devices
|
||||
ms.assetid: 7f7cd3b9-de8e-4fbf-89c6-3d1a47bc2beb
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Gathering Information about Your Devices
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
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 should not 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 is not an effective way to identify an asset because it is 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 is also important to track the current state of service packs and updates that might be installed, because these 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 completely 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](http://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 additional changes must be recorded and the updates noted in the inventory.
|
||||
|
||||
This inventory will be critical for planning and implementing your Windows Firewall with Advanced Security design.
|
||||
|
||||
**Next: **[Gathering Other Relevant Information](gathering-other-relevant-information.md)
|
||||
@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Protect Devices from Unwanted Network Traffic (Windows 10)
|
||||
description: Protect Devices from Unwanted Network Traffic
|
||||
ms.assetid: 307d2b38-e8c4-4358-ae16-f2143af965dc
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Protect Devices from Unwanted Network Traffic
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Although network perimeter firewalls provide important protection to network resources from external threats, there are network threats that a perimeter firewall cannot protect against. Some attacks might successfully penetrate the perimeter firewall, and at that point what can stop it? Other attacks might originate from inside the network, such as malware that is brought in on portable media and run on a trusted device. Portable device are often taken outside the network and connected directly to the Internet, without adequate protection between the device and security threats.
|
||||
|
||||
Reports of targeted attacks against organizations, governments, and individuals have become more widespread in recent years. For a general overview of these threats, also known as advanced persistent threats (APT), see the [Microsoft Security Intelligence Report](http://www.microsoft.com/security/sir/default.aspx).
|
||||
|
||||
Running a host-based firewall on every device that your organization manages is an important layer in a "defense-in-depth" security strategy. A host-based firewall can help protect against attacks that originate from inside the network and also provide additional protection against attacks from outside the network that manage to penetrate the perimeter firewall. It also travels with a portable device to provide protection when it is away from the organization's network.
|
||||
|
||||
A host-based firewall helps secure a device by dropping all network traffic that does not match the administrator-designed rule set for permitted network traffic. This design, which corresponds to [Basic Firewall Policy Design](basic-firewall-policy-design.md), provides the following benefits:
|
||||
|
||||
- Network traffic that is a reply to a request from the local device is permitted into the device from the network.
|
||||
|
||||
- Network traffic that is unsolicited, but that matches a rule for allowed network traffic, is permitted into the device from the network.
|
||||
|
||||
For example, Woodgrove Bank wants a device that is running SQL Server to be able to receive the SQL queries sent to it by client devices. The firewall policy deployed to the device that is running SQL Server includes firewall rules that specifically allow inbound network traffic for the SQL Server program.
|
||||
|
||||
- Outbound network traffic that is not specifically blocked is allowed on the network.
|
||||
|
||||
For example, Woodgrove Bank has a corporate policy that prohibits the use of certain peer-to-peer file sharing programs. The firewall policy deployed to the computers on the network includes firewall rules that block both inbound and outbound network traffic for the prohibited programs. All other outbound traffic is permitted.
|
||||
|
||||
The following component is recommended for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more Group Policy objects (GPOs) that can be automatically applied to all relevant computers in the domain. For more information about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
Other means of deploying a firewall policy are available, such as creating scripts that use the netsh command-line tool, and then running those scripts on each computer in the organization. This guide uses Active Directory as a recommended means of deployment because of its ability to scale to very large organizations.
|
||||
|
||||
**Next: **[Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)
|
||||
@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Restrict Access to Only Specified Users or Devices (Windows 10)
|
||||
description: Restrict Access to Only Specified Users or Devices
|
||||
ms.assetid: a6106a07-f9e5-430f-8dbd-06d3bf7406df
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Restrict Access to Only Specified Users or Computers
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Domain isolation (as described in the previous goal [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)) prevents devices that are members of the isolated domain from accepting network traffic from untrusted devices. However, some devices on the network might host sensitive data that must be additionally restricted to only those users and computers that have a business requirement to access the data.
|
||||
|
||||
Windows Firewall with Advanced Security enables you to restrict access to devices and users that are members of domain groups authorized to access that device. These groups are called *network access groups (NAGs)*. When a device authenticates to a server, the server checks the group membership of the computer account and the user account, and grants access only if membership in the NAG is confirmed. Adding this check creates a virtual "secure zone" within the domain isolation zone. You can have multiple devices in a single secure zone, and it is likely that you will create a separate zone for each set of servers that have specific security access needs. Devices that are part of this server isolation zone are often also part of the encryption zone (see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)).
|
||||
|
||||
Restricting access to only users and devices that have a business requirement can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations.
|
||||
|
||||
You can restrict access by specifying either computer or user credentials.
|
||||
|
||||
The following illustration shows an isolated server, and examples of devices that can and cannot communicate with it. Devices that are outside the Woodgrove corporate network, or computers that are in the isolated domain but are not members of the required NAG, cannot communicate with the isolated server.
|
||||
|
||||
|
||||
|
||||
This goal, which corresponds to [Server Isolation Policy Design](server-isolation-policy-design.md), provides the following features:
|
||||
|
||||
- Isolated servers accept unsolicited inbound network traffic only from devices or users that are members of the NAG.
|
||||
|
||||
- Isolated servers can be implemented as part of an isolated domain, and treated as another zone. Members of the zone group receive a GPO with rules that require authentication, and that specify that only network traffic authenticated as coming from a member of the NAG is allowed.
|
||||
|
||||
- Server isolation can also be configured independently of an isolated domain. To do so, configure only the devices that must communicate with the isolated server with connection security rules to implement authentication and check NAG membership.
|
||||
|
||||
- A server isolation zone can be simultaneously configured as an encryption zone. To do this, configure the GPO with rules that force encryption in addition to requiring authentication and restricting access to NAG members. For more information, see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md).
|
||||
|
||||
The following components are required for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant devices in the domain. For more info about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
**Next: **[Mapping Your Deployment Goals to a Windows Firewall with Advanced Security Design](mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md)
|
||||
@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Restrict Access to Only Trusted Devices (Windows 10)
|
||||
description: Restrict Access to Only Trusted Devices
|
||||
ms.assetid: bc1f49a4-7d54-4857-8af9-b7c79f47273b
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Restrict Access to Only Trusted Devices
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
Your organizational network likely has a connection to the Internet. You also likely have partners, vendors, or contractors who attach devices that are not owned by your organization to your network. Because you do not manage those devices, you cannot trust them to be free of malicious software, maintained with the latest security updates, or in any way in compliance with your organization's security policies. These untrustworthy devices both on and outside of your physical network must not be permitted to access your organization's devices except where it is truly required.
|
||||
|
||||
To mitigate this risk, you must be able to isolate the devices you trust, and restrict their ability to receive unsolicited network traffic from untrusted devices. By using connection security and firewall rules available in Windows Firewall with Advanced Security, you can logically isolate the devices that you trust by requiring that all unsolicited inbound network traffic be authenticated. Authentication ensures that each device or user can positively identify itself by using credentials that are trusted by the other device. Connection security rules can be configured to use IPsec with the Kerberos V5 protocol available in Active Directory, or certificates issued by a trusted certification authority as the authentication method.
|
||||
|
||||
>**Note:** Because the primary authentication method recommended for devices that are running Windows is to use the Kerberos V5 protocol with membership in an Active Directory domain, this guide refers to this logical separation of computers as *domain isolation*, even when certificates are used to extend the protection to devices that are not part of an Active Directory domain.
|
||||
|
||||
The protection provided by domain isolation can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations.
|
||||
|
||||
The following illustration shows an isolated domain, with one of the zones that are optionally part of the design. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory.
|
||||
|
||||
|
||||
|
||||
These goals, which correspond to [Domain Isolation Policy Design](domain-isolation-policy-design.md) and [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md), provide the following benefits:
|
||||
|
||||
- Devices in the isolated domain accept unsolicited inbound network traffic only when it can be authenticated as coming from another device in the isolated domain. Exemption rules can be defined to allow inbound traffic from trusted computers that for some reason cannot perform IPsec authentication.
|
||||
|
||||
For example, Woodgrove Bank wants all of its devices to block all unsolicited inbound network traffic from any device that it does not manage. The connection security rules deployed to domain member devices require authentication as a domain member or by using a certificate before an unsolicited inbound network packet is accepted.
|
||||
|
||||
- Devices in the isolated domain can still send outbound network traffic to untrusted devices and receive the responses to the outbound requests.
|
||||
|
||||
For example, Woodgrove Bank wants its users at client devices to be able to access Web sites on the Internet. The default Windows Firewall with Advanced Security settings for outbound network traffic allow this. No additional rules are required.
|
||||
|
||||
These goals also support optional zones that can be created to add customized protection to meet the needs of subsets of an organization's devices:
|
||||
|
||||
- Devices in the "boundary zone" are configured to use connection security rules that request but do not require authentication. This enables them to receive unsolicited inbound network traffic from untrusted devices, and also to receive traffic from the other members of the isolated domain.
|
||||
|
||||
For example, Woodgrove Bank has a server that must be accessed by its partners' devices through the Internet. The rules applied to devices in the boundary zone use authentication when the client device can support it, but do not block the connection if the client device cannot authenticate.
|
||||
|
||||
- Devices in the "encryption zone" require that all network traffic in and out must be encrypted to secure potentially sensitive material when it is sent over the network.
|
||||
|
||||
For example, Woodgrove Bank wants the devices running SQL Server to only transmit data that is encrypted to help protect the sensitive data stored on those devices.
|
||||
|
||||
The following components are required for this deployment goal:
|
||||
|
||||
- **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more GPOs that can be automatically applied to all relevant devices in the domain. For more info about Active Directory, see [Additional Resources](additional-resources-wfasdesign.md).
|
||||
|
||||
**Next: **[Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)
|
||||
@ -0,0 +1,189 @@
|
||||
---
|
||||
title: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012 (Windows 10)
|
||||
description: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Securing End-to-End IPsec connections by using IKEv2
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server 2016 Technical Preview
|
||||
|
||||
IKEv2 offers the following:
|
||||
|
||||
- Supports IPsec end-to-end transport mode connections
|
||||
|
||||
- Provides interoperability for Windows with other operating systems that use IKEv2 for end-to-end security
|
||||
|
||||
- Supports Suite B (RFC 4869) requirements
|
||||
|
||||
- Coexists with existing policies that deploy AuthIP/IKEv1
|
||||
|
||||
- Uses the Windows PowerShell interface exclusively for configuration. You cannot configure IKEv2 through the user interface.
|
||||
|
||||
- Uses certificates for the authentication mechanism
|
||||
|
||||
You can use IKEv2 as a virtual private network (VPN) tunneling protocol that supports automatic VPN reconnection. IKEv2 allows the security association to remain unchanged despite changes in the underlying connection.
|
||||
|
||||
**In this document**
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
|
||||
- [Devices joined to a domain](#devices-joined-to-a-domain)
|
||||
|
||||
- [Device not joined to a domain](#devices-not-joined-to-a-domain)
|
||||
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
|
||||
>**Note:** This topic includes sample Windows PowerShell cmdlets. For more info, see [How to Run a Windows PowerShell Cmdlet](http://go.microsoft.com/fwlink/p/?linkid=230693).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
These procedures assume that you already have a public key infrastructure (PKI) in place for device authentication.
|
||||
|
||||
## Devices joined to a domain
|
||||
|
||||
The following Windows PowerShell script establishes a connection security rule that uses IKEv2 for communication between two computers (CLIENT1 and SERVER1) that are joined to the corp.contoso.com domain as shown in Figure 1.
|
||||
|
||||
|
||||
|
||||
**Figure 1** The Contoso corporate network
|
||||
|
||||
This script does the following:
|
||||
|
||||
- Creates a security group called **IPsec client and servers** and adds CLIENT1 and SERVER1 as members.
|
||||
|
||||
- Creates a Group Policy Object (GPO) called **IPsecRequireInRequestOut** and links it to the corp.contoso.com domain.
|
||||
|
||||
- Sets the permissions to the GPO so that they apply only to the computers in **IPsec client and servers** and not to **Authenticated Users**.
|
||||
|
||||
- Indicates the certificate to use for authentication.
|
||||
|
||||
>**Important:** The certificate parameters that you specify for the certificate are case sensitive, so make sure that you type them exactly as specified in the certificate, and place the parameters in the exact order that you see in the following example. Failure to do so will result in connection errors.
|
||||
|
||||
- Creates the IKEv2 connection security rule called **My IKEv2 Rule**.
|
||||
|
||||
**Windows PowerShell commands**
|
||||
|
||||
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
|
||||
|
||||
``` syntax
|
||||
# Create a Security Group for the computers that will get the policy
|
||||
$pathname = (Get-ADDomain).distinguishedname
|
||||
New-ADGroup -name "IPsec client and servers" -SamAccountName "IPsec client and servers" `
|
||||
-GroupCategory security -GroupScope Global -path $pathname
|
||||
|
||||
# Add test computers to the Security Group
|
||||
$computer = Get-ADComputer -LDAPFilter "(name=client1)"
|
||||
Add-ADGroupMember -Identity "IPsec client and servers" -Members $computer
|
||||
$computer = Get-ADComputer -LDAPFilter "(name=server1)"
|
||||
Add-ADGroupMember -Identity "IPsec client and servers" -Members $computer
|
||||
|
||||
# Create and link the GPO to the domain
|
||||
$gpo = New-gpo IPsecRequireInRequestOut
|
||||
$gpo | new-gplink -target "dc=corp,dc=contoso,dc=com" -LinkEnabled Yes
|
||||
|
||||
# Set permissions to security group for the GPO
|
||||
$gpo | Set-GPPermissions -TargetName "IPsec client and servers" -TargetType Group -PermissionLevel GpoApply -Replace
|
||||
$gpo | Set-GPPermissions -TargetName "Authenticated Users" -TargetType Group -PermissionLevel None -Replace
|
||||
|
||||
#Set up the certificate for authentication
|
||||
$gponame = "corp.contoso.com\IPsecRequireInRequestOut"
|
||||
$certprop = New-NetIPsecAuthProposal -machine -cert -Authority "DC=com, DC=contoso, DC=corp, CN=corp-APP1-CA"
|
||||
$myauth = New-NetIPsecPhase1AuthSet -DisplayName "IKEv2TestPhase1AuthSet" -proposal $certprop –PolicyStore GPO:$gponame
|
||||
|
||||
#Create the IKEv2 Connection Security rule
|
||||
New-NetIPsecRule -DisplayName "My IKEv2 Rule" -RemoteAddress any -Phase1AuthSet $myauth.InstanceID `
|
||||
-InboundSecurity Require -OutboundSecurity Request -KeyModule IKEv2 -PolicyStore GPO:$gponame
|
||||
```
|
||||
|
||||
## Devices not joined to a domain
|
||||
|
||||
Use a Windows PowerShell script similar to the following to create a local IPsec policy on the devices that you want to include in the secure connection.
|
||||
|
||||
>**Important:** The certificate parameters that you specify for the certificate are case sensitive, so make sure that you type them exactly as specified in the certificate, and place the parameters in the exact order that you see in the following example. Failure to do so will result in connection errors.
|
||||
|
||||
**Windows PowerShell commands**
|
||||
|
||||
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
|
||||
|
||||
``` syntax
|
||||
#Set up the certificate
|
||||
$certprop = New-NetIPsecAuthProposal -machine -cert -Authority "DC=com, DC=contoso, DC=corp, CN=corp-APP1-CA"
|
||||
$myauth = New-NetIPsecPhase1AuthSet -DisplayName "IKEv2TestPhase1AuthSet" -proposal $certprop
|
||||
|
||||
#Create the IKEv2 Connection Security rule
|
||||
New-NetIPsecRule -DisplayName "My IKEv2 Rule" -RemoteAddress any -Phase1AuthSet $myauth.InstanceID `
|
||||
-InboundSecurity Require -OutboundSecurity Request -KeyModule IKEv2
|
||||
```
|
||||
|
||||
Make sure that you install the required certificates on the participating computers.
|
||||
|
||||
>**Note:**
|
||||
- For local devices, you can import the certificates manually if you have administrator access to the computer. For more info, see [Import or export certificates and private keys](http://windows.microsoft.com/windows-vista/Import-or-export-certificates-and-private-keys).
|
||||
- You need a root certificate and a computer certificate on all devices that participate in the secure connection. Save the computer certificate in the **Personal/Certificates** folder.
|
||||
- For remote devices, you can create a secure website to facilitate access to the script and certificates.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Follow these procedures to verify and troubleshoot your IKEv2 IPsec connections:
|
||||
|
||||
**Use the Windows Firewall with Advanced Security snap-in to verify that a connection security rule is enabled.**
|
||||
|
||||
1. Open the Windows Firewall with Advanced Security console.
|
||||
|
||||
2. In the left pane of the Windows Firewall with Advanced Security snap-in, click **Connection Security Rules**, and then verify that there is an enabled connection security rule.
|
||||
|
||||
3. Expand **Monitoring**, and then click **Connection Security Rules** to verify that your IKEv2 rule is active for your currently active profile.
|
||||
|
||||
**Use Windows PowerShell cmdlets to display the security associations.**
|
||||
|
||||
1. Open a Windows PowerShell command prompt.
|
||||
|
||||
2. Type **get-NetIPsecQuickModeSA** to display the Quick Mode security associations.
|
||||
|
||||
3. Type **get-NetIPsecMainModeSA** to display the Main Mode security associations.
|
||||
|
||||
**Use netsh to capture IPsec events.**
|
||||
|
||||
1. Open an elevated command prompt.
|
||||
|
||||
2. At the command prompt, type **netsh wfp capture start**.
|
||||
|
||||
3. Reproduce the error event so that it can be captured.
|
||||
|
||||
4. At the command prompt, type **netsh wfp capture stop**.
|
||||
|
||||
A wfpdiag.cab file is created in the current folder.
|
||||
|
||||
5. Open the cab file, and then extract the wfpdiag.xml file.
|
||||
|
||||
6. Open the wfpdiag.xml file with your an XML viewer program or Notepad, and then examine the contents. There will be a lot of data in this file. One way to narrow down where to start looking is to search the last “errorFrequencyTable” at the end of the file. There might be many instances of this table, so make sure that you look at the last table in the file. For example, if you have a certificate problem, you might see the following entry in the last table at the end of the file:
|
||||
|
||||
``` syntax
|
||||
<item>
|
||||
<error>ERROR_IPSEC_IKE_NO_CERT</error>
|
||||
<frequency>32</frequency>
|
||||
</item>
|
||||
```
|
||||
In this example, there are 32 instances of the **ERROR\_IPSEC\_IKE\_NO\_CERT** error. So now you can search for **ERROR\_IPSEC\_IKE\_NO\_CERT** to get more details regarding this error.
|
||||
|
||||
You might not find the exact answer for the issue, but you can find good hints. For example, you might find that there seems to be an issue with the certificates, so you can look at your certificates and the related cmdlets for possible issues.
|
||||
|
||||
## See also
|
||||
|
||||
- [Windows Firewall with Advanced Security](windows-firewall-with-advanced-security.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user