Understanding Windows CLAT (WinCLAT) Event Logging

Windows CLAT (WinCLAT) allows IPv4-only applications to continue working on IPv6-only and IPv6-mostly networks by translating their IPv4 traffic to IPv6 for delivery to a NAT64 gateway. When troubleshooting WinCLAT, checking its current state provides only part of the picture. Windows also records events that help administrators understand when WinCLAT was enabled, how it discovered the NAT64 prefix, and when translation started or stopped. This post explains where to find these events, what they mean, and how they can assist with troubleshooting.

Contents

Locating WinCLAT Event Logs

WinCLAT records events in the Microsoft-Windows-IPxlatCfg/Operational event log. In Event Viewer, the log is located under Applications and Services Logs > Microsoft > Windows > IPxlatCfg > Operational Channel. The log is enabled by default.

IPxlatCfg operational event log.

You can also use PowerShell to display the most recent events.

Get-WinEvent -LogName 'Microsoft-Windows-IPxlatCfg/Operational' -MaxEvents 10 | Format-Table -Property TimeCreated, Id, Message -Wrap

Recent WinCLAT events displayed using PowerShell.

Creating a WinCLAT Custom View

To make viewing WinCLAT event log entries easier, I recommend creating a custom view in Event Viewer. To do this, download the WinCLAT Event Viewer XML configuration file here. Next, open Event Viewer (eventvwr.msc) and perform the following steps.

  1. Right-click Custom Views and choose Import Custom View.
  2. Select the winclat-event.xml file downloaded previously and click Open.
  3. Review the Name and Description of the Custom View and click OK.
  4. Click OK.

WinCLAT events displayed in an Event Viewer custom view.

WinCLAT Event ID Reference

The following table shows the WinCLAT event IDs.

Event IDDescriptionWhen it is recorded
1106Instance enabledCLAT is enabled on an interface, automatically or manually
1107Instance disabledCLAT is disabled on an interface
1108Remote prefix discoveredCLAT discovers the NAT64 prefix for an interface
1109Translation startedCLAT begins translating on an interface
1110Translation stoppedCLAT stops translating on an interface
1111CLAT IPv6 address DAD failureThe CLAT IPv6 address fails duplicate address detection

Event ID 1106: Instance Enabled

Description: WinCLAT has been enabled on an interface. The event includes the trigger source, which identifies why WinCLAT was enabled, and the interface LUID.

When it is recorded: When WinCLAT is enabled on an interface, either automatically by Windows or manually by an administrator. The trigger source is one of the following.

CodeTrigger sourceMeaning
1Pref64 RAEnabled automatically because the network’s router advertisements include the PREF64 option
3No IPv4Enabled automatically because the interface has no IPv4 connectivity
5ManualEnabled manually with netsh.exe interface clat set instance interface=<ifIndex> state=enabled

Identifying the Trigger Source and Network Adapter

The event includes the trigger source, which identifies why WinCLAT was enabled, and the interface’s locally unique identifier (LUID). The interface LUID matches the NetLuid property returned by Get-NetAdapter. The following PowerShell commands list each event 1106 with its trigger source and adapter name.

$Adapters = @{}
Get-NetAdapter | ForEach-Object -Process { $Adapters[[uint64]$_.NetLuid] = $_.Name }
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-IPxlatCfg/Operational'; Id = 1106 } |
    Select-Object -Property TimeCreated,
        @{ Name = 'TriggerSource'; Expression = { Switch ($_.Properties[0].Value) { 1 { 'Pref64 RA' } 3 { 'No IPv4' } 5 { 'Manual' } Default { "Unknown ($_)" } } } },
        @{ Name = 'Interface'; Expression = { $Adapters[[uint64]$_.Properties[1].Value] } }

Event ID 1107: Instance Disabled

Description: WinCLAT has been disabled on an interface.

When it is recorded: When WinCLAT is disabled on an interface. This can happen in any of the following cases.

  • AutoEnable is disabled (netsh.exe interface clat set global autoenable=disabled) or Permit is disabled (netsh.exe interface clat set global permit=disabled). Both settings disable any automatically enabled instances.
  • A manually enabled instance is disabled with netsh.exe interface clat set instance interface=<ifIndex> state=disabled.
  • The network adapter of an automatically enabled instance is restarted.

Event ID 1108: Remote Prefix Discovered

Description: WinCLAT has discovered the NAT64 prefix used for translation. The event includes the discovery source, prefix, prefix length, and prefix lifetime (seconds). The source is one of the following:

  • RA – The prefix was obtained from the PREF64 option in IPv6 router advertisements (RFC 8781).
  • DNS – The prefix was obtained by querying ipv4only.arpa against a DNS64 server (RFC 7050).

When it is recorded: When WinCLAT discovers the NAT64 prefix for an interface (normally following event 1106) and when a prefix discovered through DNS is refreshed at the end of its lifetime.

Event ID 1109: Translation Started

Description: WinCLAT has started translating IPv4 traffic on an interface. The event includes the remote prefix (NAT64 prefix), the CLAT (synthetic) IPv6 address, and the CLAT (synthetic) IPv4 address, which is assigned from the IPv4 Service Continuity Prefix 192.0.0.0/29 (RFC 7335), typically 192.0.0.1.

When it is recorded: When translation begins on an interface, which normally follows events 1106 and 1108, and when Windows restarts translation on an interface that remains enabled, such as after a network adapter restart.

Event ID 1110: Translation Stopped

Description: WinCLAT has stopped translating IPv4 traffic on an interface.

When it is recorded: When translation ends on an interface. It precedes event 1107 when an instance is disabled, and it is also recorded when Windows restarts translation on an interface that remains enabled. In that case, it is followed by event 1109.

Event ID 1111: WinCLAT IPv6 Address DAD Failure

Description: The WinCLAT IPv6 address failed duplicate address detection (DAD), meaning another node on the network is already using the address.

When it is recorded: When Windows generates a CLAT IPv6 address for an interface and duplicate address detection reports a conflict.

WinCLAT Event Logging Limitations

WinCLAT events describe changes to an instance’s state, but they do not identify the applications using WinCLAT or the destination IPv4 addresses those applications access. Administrators can use Sysmon to collect this additional information. See How to Identify Applications That Use Windows CLAT (WinCLAT) with Sysmon for more details.

Summary

WinCLAT event logging helps administrators understand how WinCLAT operates on individual network interfaces. The events record instance enablement and disablement, NAT64 prefix discovery, translation activity, and address conflicts. Reviewing this history alongside the current WinCLAT configuration and interface state provides a clearer picture when troubleshooting. For visibility into the applications and destination addresses associated with WinCLAT traffic, administrators can supplement these events with Sysmon.

Additional Information

Windows CLAT (WinCLAT) PowerShell Module on GitHub.com

Troubleshooting Windows CLAT (WinCLAT) with the WinCLAT PowerShell Module

Windows CLAT (WinCLAT) Frequently Asked Questions (FAQ)

WinCLAT resources at directaccess.richardhicks.com

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Recently, Microsoft began rolling out Windows Customer-side Translator (WinCLAT) for Windows 11, allowing IPv4 applications to communicate over IPv6-only networks using 464XLAT. To translate that traffic, WinCLAT must discover the network’s NAT64 prefix. This post explains how WinCLAT learns the prefix through router advertisements or DNS, and where DHCPv4 option 108 fits into an IPv6-only deployment.

464XLAT

The 464XLAT CLAT translates an application’s IPv4 packets into IPv6 and sends them across an IPv6-only network to the PLAT. CLAT embeds the destination IPv4 address inside a special NAT64 IPv6 prefix (PREF64). The PLAT extracts the embedded IPv4 address and converts the packets back to IPv4 so they can reach the destination IPv4 address.

Well-Known Prefix

The NAT64 well-known prefix (WKP) is 64:ff9b::/96 as defined in RFC 6052. An IPv4 address is embedded in the last 32 bits of this prefix to produce a corresponding IPv6 address. In the example below, I’ve made two DNS queries for an IPv4-only resource: one to the standard Cloudflare public DNS server, and another to the Cloudflare public DNS64 server. The first response returns only an A resource record. In the second response, the server also returns an AAAA resource record using the well-known NAT64 prefix. You’ll find the last 32 bits of this record include the hexadecimal representation of the IPv4 address (ace9:996f = 172.233.153.111).

DNS queries and responses from standard and DNS64 DNS servers

This example uses the well-known prefix, but a network may use a different, network-specific NAT64 prefix (NSP). WinCLAT must discover the prefix used by the network’s PLAT before it can translate traffic correctly.

Prefix Discovery

WinCLAT can learn the NAT64 prefix in two ways. It can learn the NAT64 prefix from a PREF64 option carried in an IPv6 Router Advertisement (RFC 8781), or by querying ipv4only.arpa and extracting the prefix from the DNS64-synthesized AAAA records (RFC 7050).

Router Advertisement

NAT64 prefix discovery via RA is the preferred method. The router includes a PREF64 option in its IPv6 Router Advertisements to tell hosts which NAT64 prefix to use for 464XLAT. However, not all routers support the PREF64 option in RAs. Check whether your network equipment and software support it. If they do not, you may need a software upgrade or different equipment before you can use RA-based prefix discovery. Windows 11 clients with WinCLAT enabled use an advertised prefix to construct IPv6 destination addresses for IPv4 traffic. When both RA and DNS prefix discovery are enabled, Windows uses DNS as a fallback.

IPv6 router advertisement with PREF64 enabled

DNS

WinCLAT can also discover the NAT64 prefix through DNS. On an IPv6-only network, it sends a query over IPv6 to the network’s DNS64 resolver, requesting AAAA records for ipv4only.arpa. The ‘ipv4’ in the domain name does not mean the query travels over IPv4. It is part of a special name used for prefix discovery. The domain has two A records, 192.0.0.170 and 192.0.0.171, but no native AAAA records. The DNS64 resolver embeds those IPv4 addresses in synthesized AAAA responses using the network’s NAT64 prefix. For example, with the well-known prefix 64:ff9b::/96, the responses are 64:ff9b::c000:aa and 64:ff9b::c000:ab. The final 32 bits, c000:aa and c000:ab, represent 192.0.0.170 and 192.0.0.171, respectively. WinCLAT extracts the prefix from the responses and uses it for translation.

DNS queries and responses for the ipv4only.arpa domain using standard and DNS64 servers

DNS64 query response for the ipv4only.arpa domain

Configure Prefix Discovery

WinCLAT’s two NAT64 prefix discovery methods can be enabled or disabled independently using the pref64fromra and pref64fromdns settings configured with netsh.exe or via Active Directory group policy settings. For example, if your network advertises a PREF64 option, you can disable DNS discovery and use router advertisements alone. When both methods are enabled, DNS serves as a fallback. At least one method must remain enabled; CLAT cannot activate if both are disabled.

See Windows CLAT (WinCLAT) Overview and Configuration for guidance on configuring these options.

DHCP Option 108

WinCLAT supports networks that use DHCPv4 option 108, called IPv6-Only Preferred and defined in RFC 8925. The Windows DHCP client requests this option, which lets a DHCPv4 server indicate that the client can operate without a native IPv4 address for a specified wait period. If a DHCPOFFER contains a valid option 108, the client normally stops DHCPv4 configuration for that period and uses IPv6 connectivity instead. WinCLAT then attempts to discover the configuration it needs, and 464XLAT can provide IPv4 connectivity for applications over the IPv6-only network. Option 108 does not supply the NAT64 prefix. WinCLAT discovers that separately through router advertisements or DNS, as described previously.

DHCP Discover requesting option 108

DHCP Offer with option 108

Windows DHCP Server and Option 108

DHCP option 108 is not natively supported in Windows DHCP Server. However, administrators can create a Custom Predefined Option to enable DHCP option 108 support in their environment. You will find detailed guidance for configuring DHCP option 108 for Windows DHCP servers here.

Summary

WinCLAT allows IPv4 applications to work on an IPv6-only network by translating their traffic for a NAT64 gateway. To do this, it discovers the network’s NAT64 prefix through a router advertisement or DNS. DHCPv4 option 108 serves a separate purpose: it tells compatible clients they can defer native IPv4 configuration and rely on IPv6 connectivity.

Additional Information

Windows CLAT (WinCLAT) Overview and Configuration

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)

IPv6 Addressing of IPv4/IPv6 Translators (RFC 6052)

Windows CLAT (WinCLAT) Resources

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

IPv6

While enterprise adoption of IPv6 has been slow, it is still moving forward. For example, the U.S. federal government has mandated [M-21-07 – PDF] the transition to IPv6 to modernize its networks and enhance security, scalability, and interoperability. During the migration to IPv6, most systems will be configured with both IPv4 and IPv6, a configuration referred to as dual stack. Ultimately, the goal is the elimination of IPv4 entirely and the use of IPv6 exclusively. However, IPv6-only presents some unique challenges.

Access to IPv4

Although an organization can successfully migrate to IPv6-only networks internally, it does not control networks outside its boundaries. In some cases, a host on an IPv6-only network may need to communicate with an IPv4 resource. Administrators must deploy an IPv6 transition technology to support this scenario.

464XLAT

464XLAT, defined in RFC 6877, is a network architecture that facilitates the transition from IPv4 to IPv6 by enabling IPv4 traffic to operate over an IPv6-only network. It combines two translation mechanisms: a customer-side translator (CLAT) on the user device, which converts IPv4 packets to IPv6, and a provider-side translator (PLAT) at the network edge, which converts the IPv6 packets back to IPv4 to communicate with IPv4-only internet services. This dual-translation approach allows devices in an IPv6-only environment to access both IPv6 and IPv4 resources without native IPv4 connectivity, making it an efficient solution for networks transitioning to IPv6 while maintaining compatibility with legacy IPv4 systems. On Windows, Windows CLAT (WinCLAT) provides the CLAT component.

CLAT for Windows

Windows has long included CLAT support for cellular network interfaces. Windows CLAT (WinCLAT) extends this support to Wi-Fi and Ethernet interfaces and is generally available on Windows 11 version 25H2, starting with build 26200.9550. WinCLAT is disabled by default on non-cellular interfaces and must be permitted before it can operate. Windows also honors DHCP option 108 only while WinCLAT is permitted. WinCLAT is not available on Windows Server. For configuration details, see Windows CLAT (WinCLAT) Overview and Configuration.

IPv6-Mostly

An IPv6-mostly network, as defined in RFC 8925, provides NAT64 alongside native IPv4 and allows IPv6-only, dual-stack, and IPv4-only devices to coexist on the same network segment. Devices that can operate without IPv4 forgo an IPv4 address, while devices that still require IPv4 continue to receive one. This approach reduces IPv4 address consumption and allows organizations to move toward IPv6-only incrementally, with 464XLAT providing IPv4 access for applications that still need it.

DHCP Option 108

DHCPv4 option 108, called IPv6-Only Preferred, allows an IPv6-mostly network to signal to capable clients that they can operate without a native IPv4 address. Only clients that can operate without IPv4, usually because they include a CLAT or because all of their applications work over IPv6, request the option. When the DHCP scope is configured for IPv6-mostly operation, the server includes option 108 in its response, along with a wait time. The client then stops DHCPv4 configuration for that period, or until it reconnects to a network, and relies on IPv6 and NAT64 for connectivity. Disabling the IPv4 stack entirely during that time is optional. Clients that do not request the option obtain an IPv4 address as usual.

Option 108 and Windows Server DHCP

Commercial DHCP appliances like Infoblox and many open source DHCP platforms natively support DHCP option 108. However, no supported version of Windows Server, including the latest release (Windows Server 2025), supports DHCP option 108 natively. To enable DHCP option 108 on Windows DHCP servers, administrators can create a custom predefined option.

Custom Predefined Option

To create a custom predefined option for DHCP option 108 on a Windows DHCP server, open the DHCP management console (dhcpmgmt.msc) and perform the following steps.

  1. Right-click IPv4 and choose Set Predefined Options.
  2. Click Add.
  3. Enter IPv6 Only Preferred in the Name field.
  4. Select Long from the Data type drop-down list.
  5. Enter 108 in the Code field.
  6. Click Ok.
DHCP management console creating custom option 108 IPv6 Only Preferred with data type Long

Assigning DHCP Option 108

Once complete, perform the following steps to assign DHCP option 108 to a DHCP scope.

  1. Select an IPv4 DHCP scope.
  2. Right-click Scope Options and choose Configure Options.
  3. Select 108 IPv6 Only Preferred from the Available Options list.
  4. Enter a value in seconds, in hexadecimal format. This value is the period during which a client stops DHCPv4 configuration and operates without native IPv4. RFC 8925 sets a minimum of 300 seconds (clients treat lower values as 300) and a default of 1800 seconds. For example, 86,400 seconds (1 day) is 0x15180.
  5. Click Ok.
DHCP scope options with 108 IPv6 Only Preferred set to 0x15180

PowerShell

Custom predefined options can also be configured using PowerShell.

Custom Predefined Option

To create a custom predefined option for DHCP option 108, open an elevated PowerShell command on a Windows DHCP server and run the following command.

Add-DhcpServerv4OptionDefinition -Name 'IPv6 Only Preferred' -OptionId 108 -Type DWORD -PassThru
PowerShell output of Add-DhcpServerv4OptionDefinition creating DHCP option 108

Assigning DHCP Option 108

To assign the custom predefined DHCP option 108 to a DHCP scope, run the following PowerShell command.

Set-DhcpServerv4OptionValue -ScopeId 172.16.5.0 -OptionId 108 -Value 0x15180 -PassThru
PowerShell output of Set-DhcpServerv4OptionValue assigning option 108 to a DHCP scope

DHCP Offer

Once configured, if the client requests DHCP option 108 in its DHCP Discover, the DHCP server includes it in the DHCP Offer, as shown here. Windows DHCP Server does not send option 108 to clients that do not request it, as required by RFC 8925.

Packet capture of a DHCP Offer containing option 108 IPv6-Only Preferred

Learn More

If you are interested in learning more about IPv6-mostly and DHCP option 108, be sure to listen to the following episodes of the IPv6 Buzz Podcast.

Summary

As organizations continue their transition toward IPv6, DHCP option 108 provides administrators with a simple and effective way to reduce reliance on legacy IPv4 by signaling clients to prefer IPv6-only operation if they can support it. While Windows Server does not natively support this option, creating a custom predefined setting ensures administrators can take advantage of this important feature.

Additional Information

M-21-07 – Completing the Transition to IPv6 for U.S. Federal Government Agencies [PDF]

Windows CLAT (WinCLAT) Overview and Configuration

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

When Windows CLAT (WinCLAT) Is Used on IPv6-Mostly and IPv6-Only Networks

What is 464XLAT? CLAT and PLAT Explained

What is an IPv6-Mostly Network?

464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)

IPv6-Only Preferred Option for DHCPv4 (RFC 8925)

IPv6 Buzz Podcast on PacketPushers.Net

Windows CLAT (WinCLAT) Resources

Always On VPN Client IP Address Assignment Methods

When Always On VPN clients connect to the VPN server, they must be assigned an IP address to facilitate network communication. When using Windows Server and Routing and Remote Access Service (RRAS) for VPN services, administrators must choose between Dynamic Host Configuration Protocol (DHCP) and static address pool assignment methods.

DHCP

DHCP is a quick and easy way to handle VPN client IP address assignment. However, there are some drawbacks and limitations associated with this option. Consider the following.

Allocation

DHCP for Always On VPN clients does not work as you might expect. For example, when a VPN client connects, it does not obtain its IP address directly from the DHCP server. Instead, the VPN server leases a block of IP addresses from the DHCP server and manages those on behalf of its clients. On the DHCP server, you will see the Unique ID column of these IP address leases indicating RAS.

Address Block Size

After configuring the VPN server to use DHCP VPN client IP address assignment, the VPN server will automatically lease a block of ten IP addresses from a DHCP server. When this initial block of ten IP addresses is exhausted, the VPN server will lease another block of ten IP addresses. Administrators can increase the size of the requested address block by creating the following registry key on each VPN server.

Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IP
Value: InitialAddressPoolSize
Type: DWORD
Data: <size of DHCP pool request>

Alternatively, administrators can download Update-VpnServerDhcpPoolSize.ps1 from my GitHub repository and run it on each VPN server to increase the size of the initial DHCP address pool request.

DHCP Options

The VPN server discards all DHCP option information returned by the DHCP server. The VPN server uses only the IP address from the DHCP lease. The client is unaware of any other information in the DHCP lease.

Subnet

By default, the VPN server will only request DHCP addresses from a scope that matches the same subnet as the IP address assigned to the VPN server’s network adapter. If the VPN server has more than one network interface, it will send DHCP requests from the network interface listed on the Adapter drop-down list, as shown here.

Note: This option is only available on servers configured with multiple network interfaces. Also, if the value is set to Allow RAS to select adapter, it is best to specifically define the network interface where DHCP and DNS requests are made.

Scope Size

When using the DHCP assignment method, ensure the DHCP scope contains enough IP addresses to support the number of concurrent connections expected on all VPN servers.

IPv6

DHCPv6 is not supported on RRAS for VPN client IP address assignment. The only option for IPv6 is prefix assignment.

RRAS in Azure

DHCP is not supported when deploying RRAS in Azure. Administrators deploying RRAS in Azure to support Always On VPN must use the static address pool assignment method. More details here.

Known Issues

When using DHCP with Windows Server 2019 RRAS servers, a known issue prevents this from working correctly. Administrators can download Update-VpnServerDhcpPrivileges.ps1 from my GitHub repository and run it on each VPN server to ensure proper DHCP operation.

Increased Complexity

Since the VPN server leases IP addresses on behalf of clients and discards DHCP option information included in the lease, there’s no real benefit to using DHCP. Using DHCP only adds complexity and introduces another dependency, making the solution more brittle and difficult to manage. Using the static address pool assignment method is a better choice.

Static Pool

Implementation best practices dictate using the static address pool assignment method instead of DHCP. The following is guidance for configuring RRAS to support the static address pool option for VPN client IP address assignment.

Unique Subnet

Using a unique IP subnet is best when using the static address pool assignment method. However, this also requires configuring internal network routing to return traffic for that subnet to the individual VPN server where that subnet is assigned. Each server must have a unique IP address pool assigned. Define static address pools using subnet boundaries when configuring multiple VPN servers. Assigning IP address pools along subnet boundaries simplifies internal network routing configuration. Ensure that assigned IP address pool subnets are large enough to accommodate the total number of concurrent connections expected on each server. Be sure to overprovision to handle failover scenarios.

Same Subnet

Alternatively, administrators can assign VPN client IP addresses from the same subnet as the VPN server’s network interface. Assigning VPN client IP addresses from the same subnet as the VPN server eliminates the need for any internal network routing configuration, simplifying deployment. However, server subnets are often small and may not have enough IP address space to support numerous concurrent VPN connections. Be sure to plan accordingly.

Static IP Addresses

It is possible to assign a static IP address to an individual user. However, assigning a static IP address to a specific device is not. I will discuss static IP address assignments for Always On VPN clients in a future blog post.

Other Limitations

Here are some additional things to consider when creating a VPN client IP addressing strategy.

DNS

Always On VPN clients can be configured to register their IP address in DNS. However, the VPN client configuration controls this setting. The DHCP server does not register IP addresses in DNS when using DHCP. The client registers its IP address in DNS directly after it connects. In addition, a VPN client will receive a different IP address each time it connects to the VPN server. DNS propagation can delay hostname resolution on-premises for remote-connected VPN clients.

Selective Addressing

Regardless of which assignment method is selected, assigning different IP addresses to different types of connections is not possible. For example, a common ask is to assign user connections from one IP address pool and device connections from another. The only option to support this is to use different servers for each type of connection.

Summary

The best practice for IPv4 VPN client addressing is to use the static address pool method with a unique IPv4 subnet per server. Using static address pool assignment provides the most flexible configuration options and eliminates the dependency on internal services, making the solution more resilient and easier to manage. A unique address pool per server ensures that a large enough subnet can be defined to support the expected number of concurrent connections, regardless of the subnet size the VPN server is assigned to. Also, a unique IP subnet for VPN clients makes configuring internal firewall rules to control VPN client access easier.

Additional Information

Always On VPN and IPv6

Always On VPN Client DNS Server Configuration

Always On VPN Routing Configuration

Always On VPN RRAS Internal Interface Non-Operational

Always On VPN and IPv6

Internet Protocol version 6 (IPv6) has been with us for nearly 30 years. IPv6 adoption on the public Internet has steadily increased over the last decade, and today is approaching 50%. However, enterprise adoption of IPv6 has been surprisingly sluggish despite its numerous benefits. IPv6 includes an expanded address space that removes complex subnetting requirements and globally unique addressing that eliminates the need to perform Network Address Translation (NAT), among others. Organizations should consider deploying IPv6 internally to take advantage of these capabilities.

IPv6 and RRAS

I’ve deployed Microsoft Always On VPN for customers using IPv6 numerous times. The following describes configuration settings required to support IPv6 in a Microsoft environment using a Windows Server Routing and Remote Access (RRAS) server.

To begin, open the Routing and Remote Access management console (rrasmgmt.msc) on the RRAS VPN server, then follow the steps below to enable IPv6 support for Always On VPN connections.

Note: The configuration below assumes that IPv6 is already deployed on the internal network, either natively or dual-stacked with IPv4.

IPv6 Remote Access

Perform the following steps to enable IPv6 remote access on the RRAS VPN server.

  1. Right-click the RRAS VPN server in the navigation tree and choose Properties.
  2. Check the box next to the IPv6 Remote access server on the General tab.

Prefix Assignment

Next, an IPv6 prefix must be assigned to each RRAS VPN server. This IPv6 prefix must be unique for each server and not in use anywhere else on the internal network. Unlike IPv4, IPv6 addresses cannot be assigned from the same prefix (subnet) as the VPN server’s internal network interface. With that, ensure that internal network IPv6 routing returns traffic for the assigned IPv6 prefixes to the corresponding VPN server.

Perform the following steps to assign an IPv6 prefix for VPN client use.

  1. Right-click the RRAS VPN server in the navigation tree and choose Properties.
  2. Select the IPv6 tab.
  3. Check the box next to Enable IPv6 Forwarding.
  4. If force tunneling is required (not recommended), check the box next to Enable Default Route Advertisement.
  5. Enter an IPv6 prefix in the IPv6 prefix assignment field. Again, ensure the IPv6 prefix is globally unique, and that internal network routing is configured to return traffic to the VPN server that owns the prefix.
  6. If your RRAS server is multi-homed, select the internal network interface from the Adapter drop-down list.

DHCP

Organizations with IPv6 deployed internally may use Microsoft Windows DHCPv6 or a dedicated DNS/DHCP/IP Address Management (IPAM) (DDI) solution like Infoblox. However, Windows Server RRAS does not support DHCPv6 for VPN client IP address assignment. Administrators must manually assign an IPv6 prefix per server. However, administrators can use DHCP alongside IPv6 prefix assignment for VPN client IPv4 addressing.

Limitations

While IPv6 may solve some problems for Always On VPN administrators, it has some limitations. Here are some crucial considerations for IPv6 and Always On VPN at the time of this writing.

Traffic Filters

You cannot use IPv6 when configuring traffic filters for Always On VPN. Specifying IPv6 elements in a traffic filter rule will prevent Always On VPN from working at all. More details here.

Intune and Routing

When split tunneling is enabled, Microsoft Intune will not accept IPv6 routes using the standard IPv6 subnet prefix of /64. The UI complains that “the value must be between 1 and 32”.

You can use the custom XML deployment option to configure Always On VPN to support split tunneling correctly as a workaround.

Additional Information

Overview of IPv6

Everything You Never Knew about NAT

Disabling IPv6 Breaks Windows Server RRAS

Microsoft Always On VPN Traffic Filters and IPv6

Discussing Microsoft and IPv6 on the IPv6 Buzz Podcast (Packet Pushers)

Always On VPN Routing Configuration

When configuring Windows 10 Always On VPN, the administrator must choose between force tunneling and split tunneling. When force tunneling is used, all network traffic from the VPN client is routed over the VPN tunnel. When split tunneling is used, the VPN client must be configured with the necessary IP routes to establish remote network connectivity to on-premises resources. How those routes are established is a common source of confusion. This article provides guidance for properly configuring routing for Always On VPN clients.

Class Based Routing

IP addresses are assigned to Windows 10 Always On VPN clients from either a static pool of addresses configured by the administrator or by DHCP. If split tunneling is enabled, the client will also be assigned a class-based route that is derived from the IP address assigned to it by the VPN server, by default. If the client is assigned an IP address from the Class A network, a corresponding /8 prefix is used. For Class B networks a /16 prefix is defined, and for Class C networks a /24 prefix is used.

As an example, if the VPN server assigns the client an IP address of 10.21.12.103, a route to the 10.0.0.0/8 network is added to the client’s routing table, as shown here.

Client routing table with the class-based 10.0.0.0/8 route added by the VPN

Complex Networks

This default class-based route is of limited use though, and is only applicable when the internal network is simple and VPN clients are assigned IP addresses from the same subnet class. In the example above, if the entire internal network resides in the 10.0.0.0/8 Class A address space, all resources will be reachable by the VPN client. Any resources in the Class B or Class C subnet ranges would be unreachable without additional configuration.

Route Configuration

To configure routing for Windows 10 Always On VPN clients, first disable the default class-based route by defining the following element in ProfileXML as shown here.

<VPNProfile>
   <NativeProfile>
      <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
   </NativeProfile>
</VPNProfile>

Next, enable specific routes as needed by defining the following element(s) in ProfileXML. The example below defines routes for all private RFC 1918 networks.

<VPNProfile>
   <Route>
      <Address>10.0.0.0</Address>
      <PrefixSize>8</PrefixSize>
   </Route>
   <Route>
      <Address>172.16.0.0</Address>
      <PrefixSize>12</PrefixSize>
   </Route>
   <Route>
      <Address>192.168.0.0</Address>
      <PrefixSize>16</PrefixSize>
   </Route>
</VPNProfile>

Once implemented, the VPN client’s routing table will appear as shown here.

Client routing table after adding routes in ProfileXML

Summary

Proper routing is crucial for ensuring full network connectivity and access to internal resources for Windows 10 Always On VPN clients. When split tunneling is employed, avoid using the default class-based route and instead define specific routes using ProfileXML as required.

Additional Information

Always On VPN Client DNS Server Configuration

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Certificate Requirements for SSTP

Always On VPN Client DNS Server Configuration

Always On VPN Client DNS Server ConfigurationDNS server configuration for Windows 10 Always On VPN clients is crucial to ensuring full access to internal resources. For Always On VPN, there are a few different ways to assign a DNS server to VPN clients.

Default DNS Servers

By default, Windows 10 clients use the same DNS server the VPN server is configured to use. This is true even if the VPN client IP address assignment method is DHCP.

Always On VPN Client DNS Server Configuration

There may be some scenarios in which this is not appropriate. For example, if the DNS server is in a DMZ network and is not configured to use internal Active Directory domain DNS servers, clients will be unable to access internal resources.

DNS Server Assignment

To configure Windows 10 Always On VPN clients to use DNS servers other than those configured on the VPN server, configure the DomainNameInformation element in the ProfileXML, as shown here.

<VPNProfile>
   <DomainNameInformation>
      <DomainName>.corp.example.net</DomainName>
      <DnsServers>10.21.12.100,10.21.12.101</DnsServers>
   </DomainNameInformation>
</VPNProfile>

Note: Be sure to include the lading “.” In the domain name to ensure that all hosts and subdomains are included.

Always On VPN Client DNS Server Configuration

Reference: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp

DNS and NRPT

Once the DomainNameInformation element has been defined, the new DNS server assignment does NOT appear on the VPN virtual adapters interface. In fact, it will still be configured to use the DNS server assigned to the VPN server, just as before. Using the DomainNameInformation element instead configures the Name Resolution Policy Table (NRPT) and assigns the new DNS server to the namespace defined by the administrator. You can view the NRPT running the Get-DnsClientNrptPolicy PowerShell command.

Always On VPN Client DNS Server Configuration

Additional Information

Windows 10 Always On VPN and the Name Resolution Policy Table (NRPT)

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training