IPsec: Frequently Asked Questions

Internet Protocol security (IPsec) is a framework of open standards for ensuring private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. The Internet Engineering Task Force (IETF) IPsec working group defines the IPsec standards.

IPsec is the long-term direction for secure networking. It provides aggressive protection against private network and Internet attacks through end-to-end security. The only computers that must know about IPsec protection are the sender and receiver in the communication. IPsec provides the ability to protect communication between workgroups, local area network computers, domain clients and servers, branch offices (which might be physically remote), extranets, and roving clients.

The Windows Vista, Windows Server 2008, Windows XP, Windows Server 2003, and Windows 2000 implementations of IPsec are IETF standards-based.

For an overview of IPsec in Windows Server 2003, see the Internet Protocol Security for Microsoft Windows Server 2003 white paper.

IPsec documentation is included with Windows XP (click Start, then click Help and Support) and Windows Server 2003 (click Start, then click Help and Support). There are also IPsec sections of the Windows Server 2003 Deployment Guide and the Windows Server 2003 Technical Reference.

For a list of all the resources for IPsec in Windows, see the IPsec Web site.

Windows Server 2003 Service Pack 2 and Windows XP Service Pack 3 include the Simple Policy Update, which allows you to simplify IPsec policy configuration. For more information, see Simplifying IPsec Policy with the Simple Policy Update.

Windows Vista and Windows Server 2008 include the following improvements to IPsec:

For more information, see the “IPsec Improvements” section of New Networking Features in Windows Server 2008 and Windows Vista.

The following IETF standards define IPsec:

Firewalls are designed to monitor incoming and outgoing traffic to determine whether the traffic is allowed. The Windows implementation of IPsec can also perform this function. However, IPsec can also ensure that the incoming and outgoing traffic is secure (protected with cryptography). For example, with the correct IPsec policy settings, you can require that all communications between domain controllers be secured.

Another key difference between IPsec for Windows and firewalls is the following:

The following usage scenarios are currently recommended:

Although IPsec can be used to create secure VPN connections across the Internet for remote access and branch office connectivity, IPsec is not a technology that was designed specifically for VPN connections. IPsec is a general technology for securing IP traffic, regardless of the type of network (the Internet or a private network) on which the traffic is sent. IPsec has been defined to work in two different modes: transport mode and tunnel mode. Tunnel mode is most often used for site-to-site VPN connections. Transport mode is most often used for securing IP traffic on private networks.

Because IPsec works at the IP layer of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack, you do not have to modify existing applications to use IPsec. All TCP/IP applications can use IPsec, whereas only SSL-enabled TCP/IP applications can use SSL. IPsec is an excellent solution to securing the traffic of legacy applications.

Other points of contrast between IPsec and SSL are the following:

With IPsec for Windows policy settings, you can block or permit incoming and outgoing traffic based on:

In contrast, with Windows Firewall you can only specify exceptions (incoming traffic that is permitted) based on source IPv4 address ranges expressed as subnets and destination TCP and UDP ports.

However, with Windows Firewall, you can do the following:

Yes. The Microsoft implementation of Layer Two Tunneling Protocol over IPsec (L2TP/IPsec) for use in remote access VPNs is standards-compliant with IETF Requests for Comments (RFCs) 2661 and 3193. IPsec by itself is not suitable for remote access VPNs. For more information, see Virtual Private Networking: Frequently Asked Questions.

An IPsec Policy is a group of settings that specify IPsec behavior with regard to the types of traffic that are permitted, blocked, or secured. An IPsec policy consists of:

After IPsec policies are created, an individual IPsec policy can be assigned (activated) at the domain, site, organizational unit, and local level.

Each IPsec rule contains the following configuration items:

The rules for a policy are displayed in reverse alphabetical order based on the name of the filter list selected for each rule. There is no method for specifying an order in which to apply the rules in a policy. IPsec for Windows automatically creates an IPsec filter list and orders the list based on the most specific to the least specific filter list. For example, a filter that specified individual IP addresses would be applied before a filter that specified all addresses on a subnet.

IPsec policy is configured with the IPsec Policy Management snap-in for the Microsoft Management Console (MMC) on all versions of Windows that support IPsec. This snap-in can be used to configure both local computer and domain-based policy. This snap-in is also available from the Group Policy snap-in in Computer Configuration\Windows Settings\Security Settings.

For computers running Windows Vista or Windows Server 2008, you can use the Windows Firewall with Advanced Security snap-in.

The command line tool that you can use to configure IPsec policy depends on the version of Windows:

The predefined policies should only be used for testing and research purposes. You should create your own IPsec policy when deploying IPsec in a production environment.

An IP filter defines a specific set of IP traffic. The configuration parameters of an IP filter are the following:

An IP filter list is a set of IP filters grouped together under a common name, typically for the purpose of applying a specific filter action.

IPsec requires IP filters to define both directions the traffic between computers. Because most network communication is two-way, the Mirrored check box was added to the filter. This option automatically creates another IP filter that is identical, but for the traffic flowing in the opposite direction (the source and destination settings are switched).

A filter action defines how IPsec will handle traffic. You can specify permit, block, or secure (known as negotiate security) filter actions. When you select the secure filter action, you must also specify security methods, authentication methods, connection type, and whether to use IPsec tunneling.

Specifies whether to allow unsecured communications with computers that cannot negotiate the use of IPsec or process IPsec-secured traffic. You can use this option to secure traffic with computers on your network that are IPsec-capable while allowing unsecured communications with computers on your network that are not IPsec-capable. However, when you enable this option, unsecured traffic is allowed when IPsec negotiations with an IPsec-capable computer fail.

Specifies whether to accept initial unsecured traffic sent by another computer, but requires secure communication when replying. This option is typically enabled on a policy that is assigned to server computers when the client computers have a policy assigned in which the default response rule is enabled. This simplifies IPsec deployment because the policy assigned to the client computers does not have to be configured with additional rules that initiate secured communication to all secured servers.

Specifies whether you want to renegotiate new master key keying material each time a new session key is required. When session key perfect forward secrecy (PFS) is disabled, new session keys are derived from current master key keying material, subject to the number of times the master key keying material can be used to derive the session key. Although enabling session key perfect forward secrecy (PFS) provides greater security, performance and throughput might be impacted.

The default response rule, which can be used for all policies, has the IP filter list of <Dynamic> and the filter action of default response when the list of rules is viewed with the IP Security Policies snap-in. The default response rule cannot be deleted, but it can be deactivated. It is activated by default for all policies.

The default response rule is used to ensure that the computer responds to requests for secure communication. If an active policy does not have a rule defined for a computer that is requesting secure communication, then the default response rule is applied and security is negotiated. For example, when Computer A communicates securely with Computer B, and Computer B does not have an inbound filter defined for Computer A, the default response rule is used.

When enabled on a client computer, the default response rule allows the client to start communicating in the clear to a server with the Accept unsecured communication, but always respond using IPsec option enabled. The server will respond with a negotiation request that, if successful, protects the rest of the traffic.

Security methods and authentication methods can be configured for the default response rule. The filter list of <Dynamic> indicates that the filter list is not configured, but that filters are created automatically based on the receipt of IKE negotiation packets. The filter action of Default Response indicates that the action of the filter (permit, block, or negotiate security) cannot be configured. Negotiate security will be used. However, you can configure:

For examples of sets of IPsec rules for various IPsec deployment scenarios, see the following resources:

The netsh ipsec dump command was never implemented for two main reasons:

For computers that obtain their IPsec policy through Active Directory-based group policy, the IPsec policy applied is the one assigned to the Group Policy Object (GPO) that is closest to the computer in the Active Directory domain structure, when following the domain structure up to the root of the domain. For example, if a computer is a member of an organizational unit (OU), then the IPsec policy assigned to that OU's GPO would be the one applied. However, if the OU's GPO does not have an assigned IPsec policy, then the computer will apply the IPsec policy assigned to the GPO in the next OU up the Active Directory tree towards the root.

The IPsec policies in different GPOs are not merged. Only one IPsec policy is applied, the one assigned with the closest GPO towards the root of the Active Directory tree.

Yes. For an example, see Active Directory in Networks Segmented by Firewalls.

The default exemptions for IPsec is specified by the NoDefaultExempt registry value (located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC), which has the following possible settings:

You can change the value of the NoDefaultExempt registry key in Window Server 2003 with the netsh ipsec dynamic set config ipsecexempt value={ 0 | 1 | 2 | 3} command.

For more information, see IPsec default exemptions are removed in Windows Server 2003.

Whether you configure IPsec policies with the IP Security Policies snap-in or command line tools depends on the complexity of your planned IPsec deployment. If you are creating a simple IPsec policy to secure traffic between two computers, you should probably use the IP Security Policies snap-in to configure. If you have an existing Active Directory infrastructure, you can store the IPsec policies in Active Directory and deploy IPsec policy via GPOs. Command line configuration is most useful if the deployment involves individual computers; scripts for creating the IPsec policies can be used to quickly add the policies to the computers.

IPsec policy can be configured with persistent, dynamic, or static policies. Most commonly, IPsec is configured with a static IPsec policy. Static policies can be stored locally in the registry, or may be stored in Active Directory.

A persistent IPsec policy is a permanent IPsec policy setting that gets applied during the IPsec service startup. Persistent policies are stored in the registry. Persistent policies enhance security by providing a secure transition from computer startup to Active Directory-based or local computer IPsec policy enforcement. Persistent policies can be designed to be the most restrictive IPsec policy with an Active Directory-based or local computer policy providing additional rules. Persistent policy can also be used to ensure that Active Directory traffic is always secured by IPsec, including the retrieval of Active Directory-based Group Policy settings.

Dynamic policy can be used to create, modify, and assign IPsec rules that take effect immediately and are not stored. If the IPsec service is stopped, dynamic policy settings are lost. However, settings applied when using the netsh ipsec dynamic set config commands are not lost.

The policy export option of the IP Security Policies snap-in allows all local IPsec policies to be exported and saved as a file with an .ipsec extension. An .ipsec file can also be imported using the IP Security Policies snap-in to add IPsec policies to another computer.

Yes. After you have exported the local IPsec policy settings to a file, you can import it into a Group Policy Object or another computer's local IPsec policy.

You can use Resultant Set of Policy (RSoP), an addition to Group Policy in Windows Server 2003 and Windows XP, to view IPsec policy assignments for a computer or for members of an Active Directory system container. For more information, see Using Resultant Set of Policy to view IPsec policy assignments.

See the "Viewing IPsec policy assignment information" section of IPsec troubleshooting tools for information about determining the IPsec policy that has been applied to computers running Windows Server 2003 or Windows XP.

You can view the IPsec filter list with the IP Security Monitor snap-in provided with Windows XP and Windows Server 2003. To add the IP Security Monitor snap-in, do the following:

To view the IPsec filter list, you need to open the Main Mode and Quick Mode folders in the console tree. In the Main Mode folder, click Specific Filters to view the filters in the IPsec filter list that require security. In the Quick Mode folder, click Specific Filters to view all of the filters in the IPsec filter list. For more information about the IPsec filter list, see IPsec Filter Ordering.

From the properties of the IPsec policy in the IP Security Policies snap-in, click the Rules tab to see the list of IP filter lists and filter actions that are used by the policy.

There is no dialog box that lists IP filter lists or filter actions that are not being used by any IPsec policy. You must determine this manually by examining each IPsec policy for the IP filter lists and filter actions that are being used.

Yes. Because the TCP port being used for a RPC communication is usually dynamically determined, you must create IP filters that specify the IP addresses of the communicating computers. However, the RPC traffic for an Active Directory client computer to a domain controller should not be secured.

No. IPsec does not secure multicast or broadcast traffic. However, you can configure IPsec to block multicast or broadcast traffic.

IPsec for Windows derives an IPsec filter list from the rules of the assigned IPsec policy. The IPsec filter list, which is derived from but different than the IP filter lists configured in the IPsec policy, is the end result of the policy configuration, specifying the exact set of interesting traffic and how it is to be handled. The IPsec filter list is ordered by a weight value, which is based on how specific the originally defined IP filter is; more specific IP filters will produce IPsec filters with a higher weight value. For more information, see IPsec Filter Ordering.

Conflicting IPsec filters contain the same value for addressing, ports, and the IP Protocol field value, but have different filter actions. For example, one IPsec filter may permit and the other IPsec filter may block. When there are conflicting IPsec filters, the IPsec filter with the most restrictive filter action is added to the IPsec filter list. The block filter action is more restrictive than the secure filter action, which is more restrictive than the permit filter action.

With the Windows Server 2003 family, if you use either Kerberos V5 or certificate authentication, you can set restrictions on which computers are allowed to connect. This functionality allows you to use IPsec to allow or deny any of the following access to a server running Windows Server 2003:

When you enable certificate to account mapping in IPsec, the IKE protocol associates (maps) a computer certificate to a computer account in an Active Directory domain or forest, and then retrieves an access token, which includes the list of the user rights that are assigned to the computer. You can restrict access by configuring Group Policy security settings and assigning either the Access this computer from the network user right or the Deny access to this computer from the network user right to individual or multiple computers, as needed.

For more information about certificate to account mapping for IPsec, see Authentication methods.

Yes. You should create an exemption that permits DNS traffic (TCP port 53 and UDP port 53).

Yes. You should create an exemption that permits NetBIOS over TCP/IP name resolution traffic, commonly sent between client computers and Windows Internet Name Service (WINS) server computers (UDP port 137).

No. IPsec for Windows automatically creates the exceptions for IPsec negotiation traffic (UDP ports 500 and 4500) when the active IPsec policy requires secure traffic.

Third-party hosts are either IPsec-capable or not. If a third-party host is IPsec-capable, you can create a peer-to-peer IPsec connection between the third-party host and a Windows-based server. If a third-party host is not IPsec-capable, place the Windows servers that need to communicate with third-party hosts in the boundary zone. This solution can also be applied to IPsec-capable hosts. For more information, see the Interoperability Considerations for IPsec Server and Domain Isolation white paper.

Computers running WinPE, Windows CE, or Windows Mobile should be treated as non-IPsec-capable hosts. See the answer to the question "How do I include third-party hosts in a domain isolation deployment?" on this page.

You can either add the servers that the visiting computers need to access to the boundary zone, or you can use certificates for IPsec authentication to the specific servers and install computer certificates on the visiting computers. If the visiting computers are running Windows 2000 with Service Pack 3 or earlier, or versions of Windows prior to Windows 2000, you must add the servers that the visiting computers need to access to the boundary zone.

For more information, see the Interoperability Considerations for IPsec Server and Domain Isolation white paper.

Yes. IPsec is integrated with the Microsoft Network Load Balancing (NLB) service. For third-party clustered server solutions, the client security association (SA) times out after two minutes if one of the cluster nodes fails. However, the client will negotiate a new SA to a remaining cluster node.

For information about how to use certificate authentication, see the Active Directory in Networks Segmented by Firewalls white paper.

Configuring IPsec to secure all traffic between domain controllers and domain members is too complex to configure and manage on an ongoing basis and is not supported in Windows.

Yes. However, some third-party VPN clients disable Windows IPsec when they install, which can create IPsec implementation coexistence issues. Microsoft is working with VPN vendors to achieve better coexistence compatibility for customers who need to use both implementations simultaneously.

For information about this question, see Logging on to Windows using Kerberos: Multiple forest logon process.

The use of preshared key authentication is not recommended because it is a relatively weak authentication method. Preshared key authentication creates a master key that is less secure than digital certificates or the Kerberos V5 protocol. In addition, preshared keys are stored in plaintext and can be viewed by users with administrator-level privileges. Preshared key authentication is provided for interoperability purposes and to adhere to IPsec standards. It is recommended that you use preshared keys only for testing and that you use digital certificates or Kerberos V5 instead in a production environment.

IPsec is designed for computer-to-computer security services and is independent of the actual traffic being secured. User credentials are employed by application layer components, rather than network layer components. Additionally, IPsec might need to secure traffic before a user has logged on to the computer.

IPsec requires the following attributes for certificates used in IPsec authentication:

For additional information, see the "IKE Main Mode and Quick Mode Negotiation" section of How IPsec Works.

Names cannot be mapped to certificates in a secure way with the Domain Name System (DNS) and Windows Internet Name Service (WINS) and IP addresses can change in a Dynamic Host Configuration Protocol (DHCP) environment.

Authentications for IPsec security associations are mutual (two-way). Each IPsec peer must present credentials that the other IPsec peer validates. If your IPsec rules are configured for Kerberos authentication and there are two IPsec peers that are in different domains with a one-way trust, the IPsec peers will be unable to perform mutual authentication. One IPsec peer will be able to authenticate (the peer in the domain that trusts the other peer's domain), but the other IPsec peer will not be able to authenticate and the authentication will fail. If you configure your IPsec rules for authentication, then one-way trusts do not affect IPsec authentication.

AES is supported in Windows Vista and Windows Server 2008 with 128, 192, and 256-bit key sizes. Windows XP, Windows Server 2003, and Windows 2000 do not support AES.

Triple Data Encryption Standard is recommended because it is more secure than DES. Use DES when securing traffic to third-party IPsec peers that do not support 3DES. Windows XP, Windows Server 2003, and Windows 2000 (Service Pack 1 and higher) support 3DES.

SHA1 is recommended because it is more secure than MD5. Use MD5 when securing traffic to third-party IPsec peers that do not support SHA1. Windows XP, Windows Server 2003, and Windows 2000 (Service Pack 1 and higher) support SHA1.

Results vary because there are many factors affecting the performance of IPsec, such as processor speed and the types of network adapters. In Microsoft testing, the following results were achieved on an Intel Pentium III-based computer, running at 993 MHz, and with 384 MB of RAM:

The most time and processor-intensive part of an IPsec-secured connection is the main mode negotiation, from which the master key is derived.

IPsec offload is the offloading of IPsec cryptographic calculations to high-performance firmware on network adapters rather than having those calculations being performed using the computer's processor. Some IPsec offload adapters can perform DES, 3DES, SHA1 Hash-based Message Authentication Code (HMAC), MD5 HMAC, and even Diffie-Hellman key determination calculations. Using IPsec offload adapters can have a significant impact on performance.

Yes. IPsec for Windows supports NLB and MSCS cluster scenarios. However, IPsec sessions do not fail over. For more information, see IPsec is not designed for failover.

The Intel Pro 100 S and 3Com 10/100 S network adapters support IPsec offload.

There are no performance counters in current versions of Windows to monitor IPsec-secured traffic.

For computers running Windows 2000, you can use the IP Security Monitor tool. Click Start, click Run, type ipsecmon.exe, and then click OK.

For computers running Windows XP or Windows Server 2003, you can use the IP Security Monitor snap-in. For more information, see To start the IP Security Policy Management snap-in.

For computers running Windows XP, you can use the ipseccmd \\computer show all command.

For computers running Windows Server 2003, you can use the netsh ipsec static show or netsh ipsec dynamic show commands.

For computers running Windows 2000, you can use the IP Security Monitor tool. Click Start, click Run, type ipsecmon.exe, and then click OK SAs are listed in the Security Associations portion of the IP Security Monitor window.

For computers running Windows XP or Windows Server 2003, you can use the IP Security Monitor snap-in. For more information, see To start the IP Security Policy Management snap-in.

For computers running Windows XP, you can use the ipseccmd\\computershow all command.

For computers running Windows Server 2003, you can use the netsh ipsec static show or netsh ipsec dynamic show commands.

You can verify that the IPsec service has been started through the net start command. For computers running Windows XP or Windows Server 2003, look for "IPSEC Services" in the list of started services. For computers running Windows 2000, look for "IPSEC Policy Agent" in the list of started services. To start the IPsec service, type net start ipsec or use the services snap-in.

Ipseccmd.exe is included with Windows XP with no service packs installed and Windows XP with Service Pack 1. For Windows XP with Service Pack 2, you can obtain a new version of Ipseccmd.exe from Windows XP SP2 Support Tools for Advanced Users.

The Oakley log records all IKE (ISAKMP) main mode and quick mode negotiations. To enable Oakley logging, do the following:

The Oakley log is stored in the systemroot\Debug folder. A new Oakley.log file is created each time the IPsec policy agent is started and the previous version of the Oakley.log file is saved as Oakley.log.sav.

Whenever asked by a network administrator or a Microsoft support engineer.