A Guide to Domain Isolation for Security Architects

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Vista

Learn how to assess the enterprise environment, plan domain isolation, and assess the implications of deploying domain isolation in an enterprise environment. Designed for security architects of enterprise organizations that are investigating using IPsec in Microsoft Windows to deploy domain isolation.

Domain isolation is the use of Internet Protocol security (IPsec) to require authentication, encryption, or both, among members of a Windows domain as well as between members of the domain and unknown or unauthorized computers. The goal of domain isolation is to isolate secured computers from unsecured computers by providing an additional level of protection for the traffic that is sent on a network. By using IPsec you add an additional defense-in-depth layer to the mechanisms that currently secure your network. IPsec-based communication changes the format of the TCP/IP packets transmitted over your network, which requires careful study and planning to mitigate risks and ensure success. This paper presents an overview of the three steps a security architect should follow to prepare for IPsec deployment:

  1. Determine the current state of your IT infrastructure

  2. Plan isolation groups

  3. Consider operational issues for IPsec-based traffic

Knowledge Prerequisites

Prior to reading this paper you should read Domain Isolation with Microsoft Windows Explained at https://go.microsoft.com/fwlink/?LinkId=44642.

In addition, make sure that you have a thorough understanding of the following topics before you begin IPsec domain isolation:

  • TCP/IP and core networking principles.

  • Windows authentication, including use of the Kerberos V5 protocol and public key infrastructure (PKI).

  • Active Directory concepts, including Active Directory structure and tools; users, groups, and other Active Directory objects; and Group Policy.

  • Windows system security, including security concepts such as users, groups, auditing, and access control lists (ACLs).

  • A thorough understanding of Windows Server 2003 IPsec policies. For more information, see the Windows Server 2003 Technical Reference at https://go.microsoft.com/fwlink/?LinkId=21711.

Determining the Current State of Your IT Infrastructure

Before starting the planning process for a domain isolation project, you need to collect and analyze up-to-date information about the current state of your IT infrastructure. A thorough and accurate assessment of your infrastructure provides the basis for planning what to isolate and how isolation should be implemented. Perform your data collection in three phases:

  • Identify network configuration

  • Map Active Directory infrastructure

  • Identify host configuration

Identifying Network Configuration

Determining the current state of your network involves gathering information about network segmentation and infrastructure devices, and then performing an analysis of network communication.

Network Segmentation

Determine what networks are in place and what hosts exist on those networks. Typically, this information is illustrated by using schematic diagrams.

Figure 1 shows a very simple network diagram.

Art Image

Network Infrastructure Devices

Next in your assessment, review the devices that make up the network infrastructure — routers, switches, load balancers, and firewalls. These devices are required to process IPsec-based traffic after the isolation solution is implemented. For this reason, it is important to determine whether these devices can handle the technical and physical requirements of the isolation design. Some of the characteristics to examine include:

  • Response to datagram change. IPsec without encryption changes the offset for the destination ports and protocols within the TCP/IP packet. These changes might limit the functionality of traffic analysis applications, such as Cisco NetFlow.

  • Normal and peak utilization. Peak use information can help determine whether the device is capable of using IPsec or if a memory or firmware upgrade is needed. If problems arise after IPsec is implemented, normal utilization data can assist in determining if the cause is related to high utilization of the device.

  • Whether the device is performing network address translation (NAT). To allow IPsec-based traffic to pass through a NAT device, you must ensure that IPsec NAT-T is supported on your IPsec peer computers.

  • Internal vs. external subnets and firewall configuration. When a firewall or filtering router exists between IPsec peers, it must be configured to forward IPsec traffic on UDP source and destination port 500 for Internet Security Association and Key Management Protocol (ISAKMP), UDP source and destination port 4500 (IPsec NAT-T), IP protocol 50 for Encapsulating Security Payload (ESP), or IP protocol 51 for Authentication Header (AH).

For specific considerations for network infrastructure devices, see “Considering Operational Issues for IPsec-based Traffic" in this paper.

Network Communication

A thorough analysis of the communication flow on your network will provide three vital pieces of information:

  • What communication is currently taking place between hosts

  • What communication should be restricted

  • What communication is at risk of failing when secured with IPsec

When you examine traffic flow, look closely at how all network devices interact. Keep in mind the following questions:

  • What protocols and ports do servers and clients use to communicate with each other?

  • Are there any security devices or projects that are implemented or planned that could impact the isolation project?

  • Are certificates used to provide authentication?

  • Do you have subnets that are dedicated to specific types of traffic (for example, Macintosh workstations and UNIX workstations, or mainframe-to-terminal connections)?

Mapping Active Directory Infrastructure

Active Directory is the next source from which to gather information. Make sure that you understand the forest structure, including domain layout, organizational unit (OU) architecture, Group Policy, and site topology. This information provides the logical placement of computers, their configuration, and the impact to Active Directory as a result of implementing IPsec. For Active Directory, determine the following:

  • Number of forests. The forest is the security boundary in Active Directory. Therefore, make sure that you understand the current Active Directory architecture because IPsec communication across forests is possible only if external trusts are configured.

  • Names and number of domains. Active Directory domains are the building blocks of domain isolation. Therefore, computers that are domain members are assumed to support IPsec using Kerberos V5 authentication.

  • Number and types of Active Directory trusts. Trusts affect the logical boundaries of isolation and can define how IKE authentication occurs. Active Directory trusts can affect Kerberos-based IKE authentication.

  • Names and number of sites. Site architecture should be aligned with network architecture.

  • OU structure and Group Policy. Organizational units can be used to apply IPsec policy. Review the OU structure to determine how Group Policy is used and how OUs are organized.

  • Existing use of IPsec policy. Multiple IPsec policies that are assigned in different Group Policy objects (GPOs) are not merged. The IPsec policy applied is the one assigned to the GPO that is closest to the computer in the Active Directory domain structure. More IPsec policies in your environment means more complexity in your domain isolation design.

Host Configuration

The final piece of your current network environment assessment is a review of client and server host computers. IPsec-based communication depends on host systems meeting specific operating system and application requirements. Useful host information to gather includes:

  • Operating system, service pack, and hotfix versions. The operating system version is a key factor in determining the ability of a host to communicate with IPsec. It is also important to track the current state of service packs and hotfixes that can be installed because these are often used to confirm that the minimum security standards have been met.

  • Domain membership. This information is used to determine whether a computer can obtain IPsec policy from Active Directory or whether it must use a local IPsec policy. Hosts that are not domain members can use a local IPsec policy applied via scripts.

  • Physical location. This information is simply the location of the device in your organization. It can be used to determine whether a device should participate in a particular isolation group based on its location or the location of the hosts that it communicates with regularly.

  • Hardware type and role. This information can help determine the eligibility of a particular computer to participate in isolation and the isolation group in which to place the computer.

For More Information

Various methods can be used to gather data from the devices on your network. These methods range from high-end, fully automated systems to completely manual data collection. Generally, the use of automated methods to gather data, such as Microsoft® Systems Management Server, is preferred over manual methods for reasons of speed and accuracy. For more information about how SMS 2003 can help perform asset management, see the demonstration and the asset management datasheet on the SMS 2003 Asset Management page at https://go.microsoft.com/fwlink/?LinkId=45078.

For more information about determining your current network configuration, see "Chapter 3: Determining the Current State of Your IT Infrastructure" available at https://go.microsoft.com/fwlink/?LinkId=45130.

Planning Domain Isolation

With a good understanding of your company’s network and host configuration, you are ready to specify your isolation domain. You can do this in four phases:

  • Define isolation

  • Determine isolation groups

  • Specify communication paths and IPsec policies

  • Complete implementation steps

Defining Isolation

Domain isolation is the use of Internet Protocol security (IPsec) to require authentication, encryption, or both, among members of a Windows domain as well as between members of the domain and unknown or unauthorized computers. In order to be a member of an isolated domain, a host must meet these minimum requirements:

  • Domain membership. The host must be a member of an Active Directory domain.

  • Ipsec-compatible operating system. The host must run an operating system that is IPsec-compatible such as Windows 2003, Windows XP, or Windows 2000 SP4.

Your organization might decide to add further requirements for security such as:

  • A properly installed and configured antivirus program with up-to-date signature files

  • Current security updates

  • Current service packs

Hosts failing to meet minimum requirements — and whatever additional requirements your organization adds — cannot be included in the isolated domain. These hosts will be restricted from communicating with domain isolation members.

Determining Isolation Groups

The primary goal of domain isolation is to restrict the communication between isolated and non-isolated hosts. For planning purposes, it is useful to combine hosts into logical groups called isolation groups. An isolation group is a device for grouping host computers that share the same inbound and outbound network traffic requirements.

In Windows, isolation groups are implemented by placing hosts in organizational units (OUs) or security groups, and then by applying policy or by assigning access permissions. An isolation group’s inbound and outbound access controls can be implemented by IPsec policy using permit/block actions, or by using IPsec policy in combination with Group Policy network access rights.

Figure 2 illustrates a simple isolation group design.

Art Image

In this example, four groups are created for domain isolation:

  • Isolation domain. This is the default group for all isolated computers and will likely be the group with the largest number of hosts. If the domain includes bidirectional trusted domains, members of those domains would be part of the isolation domain. All host-to-host communication within this group is secured by using IPsec.

  • Non-isolated hosts. This group contains all non-isolated computers not capable of IPsec-based communication, such as Macintosh and UNIX computers.

  • Boundary isolation. This group contains isolated hosts that will be allowed to communicate with non-isolated and isolated hosts. These computers will be exposed to a higher level of risk because they can receive incoming communications directly from unsecured computers. For example, you might want your Remote Installation Services (RIS) servers, which support downloading operating system images to computers that are not yet IPsec-compatible, to be boundary hosts.

  • Exemption lists. This group contains computers that are by default in your isolated domain, but that must be available to all systems on the network. For example, you might want your domain controllers, and DNS, DHCP, and WINS servers to be exempted.

All computers on your network that share the same communications security policy are assigned to one of the isolation groups. After the groups are designed and host membership decided, you’re ready to plan the network traffic between the isolation groups.

Specify Communication Paths and IPsec Policies

At this point in the planning process, the communications traffic requirements that will be allowed to pass between the groups need to be documented, along with the form the communications will take. Figure 3 illustrates communication paths for the isolation groups.

Art Image

After IPsec policies are in place for the isolation groups, communication between the groups will proceed as shown in the following table.

Path Groups Communication

1

From non-isolated hosts to hosts in the boundary group

Unsecured, plaintext TCP/IP connections.

2

From boundary group hosts to non-isolated hosts

Hosts attempt to communicate with IPsec-based traffic but can fall back to non-IPsec-based communication (the Fall back to clear option).

3

Between hosts in the isolation domain and boundary groups

Hosts attempt to use IPsec to protect the traffic. This traffic might require encryption, depending on the security requirements. If the IKE negotiation fails, the communications will fail because there is no Fall back to clear option when IKE negotiation fails.

4

From isolated hosts to non-isolated hosts

Hosts attempt to communicate with IPsec-based traffic but will fall back to non-IPsec-based communication.

5

From non-isolated hosts to isolated hosts

Blocked from initiating communication.

Though not included in the diagram or table, all hosts are allowed to communicate with hosts in the exemption lists group using unsecured, plaintext connections.

Implementation Steps

With a complete understanding of your network and a plan for controlling traffic with isolation groups, you are now ready for the next steps in your utilization of IPsec to secure your network. These steps include:

Considering Operational Issues for IPsec-based Traffic

IPsec provides greater security at the expense of network and processing performance and compatibility with other services, tools, and features. The following section describes these and other important operational considerations for managing IPsec policies.

The Impact of IPsec on Performance

IPsec has some costs in network and processor performance. The exact cost cannot be predicted because it depends on many factors, such as the level of application traffic and the number and configuration of IPsec filters deployed. However, the following factors should be understood and reviewed for your deployment.

Network Performance

IPsec impacts network performance in two ways.

IKE SA establishment slows connection establishment.

When a security association (SA) is initially established between two computers, a delay of up to three seconds occurs while security is negotiated. This time might vary depending on policy design, the authentication method that is selected, network roundtrip time, and the load placed on the servers required to establish the connection. Accordingly, end users might notice brief initial delays when IPsec-based connections are established. Typically, after SAs are established, no further delays occur.

Large packet headers reduce throughput and increases network utilization.

For each IPsec-based packet, the AH and ESP headers add an additional 24 to 36 bytes of data, depending on which method of encapsulation is used and whether IPsec tunneling is used. This decreases the effective IP payload size for upper-layer protocols such as TCP and UDP. As a result, traffic that is secured by IPsec uses more packets than traffic that is not secured by IPsec. The Microsoft IT department observed a mean bandwidth usage increase of 3 percent when they deployed IPsec (ESP-Null) across their network.

Different enterprise environments might experience a different amount of increased usage, depending on the mix of applications present. The increase in bandwidth usage is likely to have a more significant effect in a WAN scenario where the traffic is already near capacity, than in a LAN over Fast Ethernet connections.

Processor Performance

IPsec impacts processor performance in two ways.

SA maintenance affects scalability and increases CPU and memory overhead.

Performance degradation and lower throughput might be experienced by servers that must establish IPsec-based communications with many clients. In particular, full ESP-encrypted traffic places the highest burden on server CPU and can gain the most benefit from the use of offload network adapters. Typically, for each active IPsec client, 5 to 20 kilobytes (KB) of memory is used on a server. The IKE authentication method has the greatest impact on memory usage for each active IPsec client. For example, Kerberos V5 authentication typically requires less memory per SA than certificate authentication.

Per-packet processing overhead increases CPU and memory overhead.

Each IPsec-based packet creates additional performance overhead for encryption, authentication, and other packet processing functions. Each packet that is not secured by IPsec must still pass through all IPsec filters. Therefore, when you configure an IPsec policy, make sure that you create the minimum number of filters required for your environment. The impact of IPsec on throughput varies in proportion to the rate at which traffic is sent or received. Typically, active IPsec policies with 500 or fewer filters result in only a minor impact on throughput. In IPsec for Windows XP and Windows Server 2003, the per-packet processing performance is significantly improved, compared to the per-packet processing performance in IPsec for Windows 2000.

The effects of IPsec on CPU performance are typically negligible on clients because clients often have ample, spare CPU processing power and memory to accommodate IPsec. However, servers that have highly loaded CPUs might incur a significant increase in load, depending on the amount of traffic that must be secured by IPsec, the number of SAs that must be processed, and the cryptographic algorithms that are selected.

If your servers already have high loads on their CPUs, consider using IPsec offload network adapters before deploying IPsec. IPsec offload network adapters accelerate cryptographic operations used to secure IPsec packets. However, these adapters do not accelerate filter processing time. IPsec-enabled network adapters can be used with Windows 2000, Windows XP, and Windows Server 2003. Such network adapters typically complete IPsec operations at such a high rate that there is minimal change in transmission speeds, resulting in minimal performance degradation. However, such adapters generally have a maximum number of SAs that they can support, after which additional SAs are processed by Windows IPsec.

Crossing Security Boundaries with IPsec Traffic

When you design an IPsec policy, it is important to consider security boundaries, such as NATs, firewalls, and forests, that IPsec-based traffic must cross. Within a TCP/IP packet, IPsec changes the offsets for the destination ports and protocols. These changes might adversely affect the transmission of data over network devices and should be researched prior to IPsec deployment.

NAT Traversal

If traffic between the client and a server must pass through a network address translator (NAT), then IPsec cannot secure the traffic (the IKE negotiation will fail when translated by a network address translator). IPsec NAT traversal (NAT-T) allows IPsec peers that are behind NATs to detect the presence of NATs, negotiate IPsec SAs, and send ESP-protected data, despite the fact that the addresses in the IPsec-protected IPv4 packets change. IPsec NAT-T does not support the use of AH across network address translation. For more information about how IPsec NAT-T works, see IPsec NAT Traversal Overview, the August 2002 Cable Guy article at https://go.microsoft.com/fwlink/?LinkId=45080.

IPsec NAT-T is supported by Windows Server 2003, Windows XP with Service Pack 2 (SP2). IPsec NAT-T is also supported by Windows XP with Service Pack 1 (SP1) and Windows 2000 if used in combination with a free Web download. However, due to the behavior of IPsec and NATs, Windows XP SP2 by default no longer supports establishing IPsec NAT-T SAs to servers that are located behind NATs to avoid a perceived security risk.

If you must send IPsec-based communication across a NAT device, it is recommended that public IP addresses be used for all servers that can be connected to directly from the Internet. If this configuration is not possible, then the default behavior of Windows XP with SP2 can be changed to enable IPsec NAT-T security associations to servers that are located behind a network address translator.

In addition, servers running Windows Server 2003 also require a hotfix so that they can be reached by hosts on the other side of a NAT device. The hotfix will be included in the Windows Server 2003 SP1 release. (This hotfix can currently be obtained from Microsoft Product Support Services.)

To ensure that a server is reachable behind a NAT for IPsec traffic, you must configure the NAT with static translation entries that map UDP port 500 (IKE) and UDP port 4500 (IPsec NAT-T) traffic to the server.

For additional information, see the following articles:

Creating Firewall Filters to Permit ISAKMP, AH, and ESP Traffic

In some cases, IPsec-based traffic might need to pass through a router, firewall, or other filtering device. In the case of a router, unless the router filters TCP and UDP traffic or other upper-level protocol headers, no special configuration is required to permit the IPsec-based traffic to be forwarded. In the case of a filtering router or a firewall, you must configure these devices to allow IPsec-based traffic to be forwarded.

In order for IPsec-based communications to pass through a firewall or other filtering device, you must configure the firewall to permit IPsec traffic on UDP source and destination port 500 (ISAKMP), UDP source and destination port 4500 (IPsec NAT-T) and IP Protocol 50 (ESP). You might also need to configure the firewall to permit IPsec traffic on IP protocol 51 (AH) to permit troubleshooting by IPsec administrators and to allow the traffic to be inspected while it is still IPsec-protected.

For more information, see How to Enable IPsec Traffic Through a Firewall on the Microsoft Support Site at https://go.microsoft.com/fwlink/?LinkId=45085.

Different Trust Environments

When you design an IPsec policy, consider any logical boundaries that might affect IPsec-based communications. For example, your domain and trust environment is 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 trusted domains whether the domains are in the same forest or in 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 you must configure the IPsec policy to allow an IKE initiator to communicate to any domain controller in the other forest, so the initiator can obtain a Kerberos ticket from a domain controller in the responder’s domain. If the domains are on opposite sides of a firewall, then you must configure the firewall to allow Kerberos traffic over UDP destination port 88, TCP destination port 88, as well as UDP destination port 389.

For more information, see Active Directory in Networks Segmented by Firewalls, available at https://go.microsoft.com/fwlink/?LinkId=45087.

If the use of Kerberos is not possible because two-way trusts across forests cannot be established as in some large enterprise environments, you can use a PKI and digital certificates to establish IPsec-based communication. For an example of how Microsoft deployed their PKI, see Deploying PKI Inside Microsoft at https://go.microsoft.com/fwlink/?LinkId=45088.

Operational Considerations

In addition to the impact of IPsec on security boundaries, other operational areas of your network will likely be affected by an IPsec deployment. These areas include: non-IPsec-compatible support, NLB clusters, and network inspection technologies.

Support for IPsec-Incompatible Hosts

In most organizations, some workstations or servers cannot communicate by using IPsec. Such hosts include:

  • Non-Windows-based computers and devices, such as Macintosh computers, UNIX computers, and personal digital assistants (PDAs).

  • Hosts running older versions of the Windows operating system. Computers running Windows NT, Windows 95, Windows 98, and Windows Millennium Edition do not support Group Policy or IPsec policies.

  • Windows-based computers that are not domain members. Stand-alone computers cannot perform IKE authentication using the Kerberos V5 protocol. A computer that is joined to a domain that is not trusted by the forest being used as the trust boundary for IKE authentication cannot participate in a domain isolation solution.

  • Other non-Windows-based remote access or VPN clients. If a non-Windows-based IPsec virtual private network (VPN) client is being used for an organization's remote access solution, it typically is not compatible with Windows IPsec. If Windows IPsec cannot be used, the host cannot participate in an IPsec domain isolation solution.

In an IPsec-based network, these hosts would likely be considered non-isolated and communication with them would be blocked. However, business requirements often exist for these computers to communicate with isolated hosts in the isolation domain.

To deal with this situation, you can create a boundary group that contains hosts that will be allowed to communicate with non-isolated hosts. These boundary hosts will be exposed to a higher level of risk because they can receive incoming unsecured communications directly from non-isolated computers. Computers in the boundary group are isolated hosts that can communicate both with other isolated hosts and with non-isolated hosts.

Boundary hosts will attempt to communicate using IPsec by initiating an IKE negotiation to the originating computer. If no IKE response is received within three seconds, the host will use plaintext without IPsec. Because plaintext communication is allowed, these hosts must be secured in other ways or monitored for acceptable risk. For more information about planning and deploying boundary groups, see Chapter 4: Designing and Planning Isolation Groups available at https://go.microsoft.com/fwlink/?LinkId=45131.

NLB Clusters

There are challenges in implementing IPsec on Network Load Balancing (NLB) clusters and server clusters. NLB allows multiple servers to be clustered together to provide high availability for a service by providing automatic failover to other nodes in the cluster if an individual server fails. IPsec directly opposes NLB in that it prevents different computers from handling the same client connection. Because IPsec is negotiated between individual hosts before any data is transmitted, the same node in the cluster must respond to established IPsec connections or the traffic will be dropped.

If the particular node in the cluster fails, existing IPsec connections to that server cannot detect the failover and attempt to rebuild the security association until the preset time-out period expires. In Windows 2000 and Windows XP, IPsec must be idle for five minutes before the client attempts to re-authenticate. This results in a two-to-six minute interruption in service for that client.

Windows XP SP1 (with the NAT-T update), Windows XP SP2, and Windows Server 2003 reduce the preset time-out period to one minute. There will always be a delay if a client happens to be connected to a cluster node that fails.

For more information about IPsec and configuring NLB clusters, see the following articles on the Microsoft Support Site:

Network Inspection Technologies

Within a TCP/IP packet, IPsec changes the offsets for the destination ports and protocols. These changes adversely affect many applications running on network devices like routers that monitor and manage traffic on the network.

Some network applications are updated to support IPsec, but many are not yet compatible:

  • Router access control lists (ACLs) cannot 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.

  • Cisco NetFlow on routers cannot analyze packets between IPsec members based on protocol or port. Analysis based only on IP address is unaffected.

  • Router-based Quality of Service (QoS) cannot use ports to classify packets. Host-based classification of packets supported by Windows is unaffected, as is router-based QoS using only IP addresses.

  • Weighted Fair Queuing (WFQ) and other flow-based router traffic prioritization methods might not queue packets as intended resulting in suboptimal network utilization.

  • Network monitoring tools might be unable to parse ESP packets that are not encrypted (ESP-Null).

In general, IPsec defeats network-based prioritization and port- or protocol-based traffic management. For encrypted packets, there is 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 it is not possible to upgrade monitoring or management devices to support IPsec, it is vital that this information be recorded and figured into your isolation design.

Network Monitor added an ESP parser in version 2.1 to aid troubleshooting of unencrypted IPsec packets. Network Monitor is available in a light version in Windows Server 2003 and a full version for SMS. The SMS version adds formatting of data, advanced diagnostic capabilities, and other features for capture management.

The version of Network Monitor that is provided with Windows Server 2003 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 cannot parse the encrypted portions of IPsec-based ESP traffic when encryption is performed in software. However, if encryption is performed by an IPsec hardware offload network adapter, the ESP packets are decrypted when Network Monitor captures them on either the source or the destination and, as a result, they can be parsed and interpreted into the upper-layer protocols. If you need to diagnose ESP software-encrypted communication, you must disable ESP encryption and use ESP-null encryption by changing the IPsec policy on both computers.

Summary

The use of IPsec to isolate computers that belong to an Active Directory domain requires careful planning. Three steps presented in this paper will prepare the security architect for the necessary research and cross-team communication. The three steps presented in this paper are: Determine the current state of your IT infrastructure, plan isolation groups, and consider operational issues for IPsec-based traffic.

See Also

Other Resources

Server and Domain Isolation Using IPsec and Group Policy Windows Server IPsec page Deploying IPsec https://go.microsoft.com/fwlink/?LinkId=31789 Interoperability Considerations for IPsec Server and Domain Isolation Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPsec) Using Microsoft Windows IPsec to Help Secure an Internal Corporate Network Server Problems with Using Network Address Translators Domain Isolation with Microsoft Windows Explained