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

Always On VPN DNS Registration Update Available

Recently, I wrote that Microsoft has begun rolling out Windows CLAT (WinCLAT) for IPv6-mostly and IPv6-only networks. I also described how WinCLAT discovers the NAT64 prefix. This post explains the conditions under which it operates, which traffic uses it, and several practical deployment scenarios.

What WinCLAT Does

Windows customer-side translator (WinCLAT) helps IPv4-dependent applications work when a Windows 11 device connects to an IPv6-only network. It can also operate on an IPv6-mostly network when the device forgoes a native IPv4 address. WinCLAT translates IPv4 traffic generated by the device, while applications that use IPv6 natively can communicate without it. Microsoft currently offers the noncellular Windows CLAT feature in public preview for evaluation.

When WinCLAT Operates

Enabling WinCLAT permits it to operate on eligible non-cellular interfaces but does not mean every connection will be translated. The client must have IPv6 connectivity using Stateless Address Autoconfiguration (SLAAC), operate without native IPv4 connectivity on the interface, and discover a usable NAT64 prefix through a router advertisement or DNS. The network must also provide a NAT64 gateway, known as the provider-side translator (PLAT), that can reach the IPv4 destination. When an application generates IPv4 traffic, WinCLAT translates its packets into IPv6 for delivery to the PLAT.

When WinCLAT Does Not Activate

If a device has working native IPv4 connectivity on a conventional dual-stack network, its IPv4 traffic uses that connectivity. If the network does not provide NAT64 or the client cannot learn its prefix, WinCLAT cannot provide access to IPv4 destinations. Merely enabling the Windows setting does not turn an ordinary IPv6 network into a 464XLAT network.

SLAAC Addressing Requirement

The current Windows implementation also requires SLAAC for the client’s IPv6 address. A network that assigns addresses exclusively through stateful DHCPv6 does not meet this requirement.

Which Traffic Uses WinCLAT?

The address family used by a connection determines whether it needs WinCLAT. An application that opens an IPv4 socket, including one that connects to a literal IPv4 address such as https://10.21.12.83 or \\172.16.21.12\data, generates IPv4 traffic. On an eligible IPv6-only interface, WinCLAT translates that traffic to IPv6, and the PLAT translates it to IPv4 for delivery to the destination. WinCLAT uses 192.0.0.1/32 locally for IPv4 compatibility. That address belongs to the 192.0.0.0/29 IPv4 Service Continuity Prefix reserved by RFC 7335. It does not represent native IPv4 connectivity, and the translated IPv4 packets are not sent on the IPv6-only physical network.

IPv6 Traffic Bypasses WinCLAT

An IPv6-capable application connecting to a native IPv6 destination uses IPv6 directly. If its destination is IPv4-only, the application can instead receive a DNS64-synthesized AAAA record and reach it through NAT64 using IPv6. In that case, the traffic does not pass through WinCLAT. DNS64 cannot help an application that insists on an IPv4 socket or a literal IPv4 address, which is where WinCLAT becomes useful.

Hostname access via DNS64 and NAT64 on an IPv6-only network. The application uses a synthesized AAAA record and native IPv6 – WinCLAT is not the path. The only translator is the PLAT/NAT64 gateway.

WinCLAT Deployment Examples

The following are example scenarios used to illustrate when and how WinCLAT works.

IPv6-Only Network

On an IPv6-only network, a Windows device receives an IPv6 address using SLAAC but no native IPv4 address. The router advertises a network-specific NAT64 prefix using PREF64, and a NAT64 gateway has a route to an IPv4-only management server. A legacy tool connects to that server using an IPv4 socket. WinCLAT translates the tool’s outbound packets into IPv6 and translates the replies for the application.

Connecting to a Literal IPv4 Address

The management tool might be configured with the server’s IPv4 address instead of its host name. Because the application does not perform a name lookup, DNS64 has no opportunity to synthesize an AAAA record. WinCLAT constructs an IPv6 destination using the discovered NAT64 prefix and the server’s IPv4 address. A capture on the endpoint’s network interface would show IPv6 traffic toward that prefix, while the application continues to see an IPv4 connection.

WinCLAT on an IPv6-only network when an application uses a literal IPv4 address. The client translates at WinCLAT and the PLAT/NAT64 gateway translates back to IPv4.

WinCLAT NAT64 prefix and IPv6 address configuration.

Application traffic using IPv4 via WinCLAT.

Packet capture showing WinCLAT translated traffic using the discovered NAT64 prefix.

IPv6-Mostly Network

An IPv6-mostly network provides NAT64 while retaining IPv4 service for devices that need it. DHCPv4 option 108, called IPv6-Only Preferred, allows a compatible client to forgo a native IPv4 address for the indicated period. If the network also provides SLAAC and a discoverable NAT64 prefix, WinCLAT can carry that client’s IPv4 application traffic over IPv6. WinCLAT discovers the NAT64 prefix separately because option 108 does not supply this information. See How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix for more information.

Supporting IPv4 and IPv6-Only Clients Together

For example, an enterprise could enable option 108 on a Wi-Fi subnet that provides SLAAC and NAT64. A WinCLAT-capable Windows laptop uses IPv6 and does not consume a native IPv4 lease. A legacy printer or another device that does not request option 108 can still receive an IPv4 address on the same subnet. If an application on the laptop opens an IPv4 socket to an IPv4 service, the laptop uses WinCLAT for that connection.

Packet capture showing DHCPv4 parameter request list indicating support for IPv6-only.

IPv4-Only Application and IPv6-Capable Browser

Two applications on the same IPv6-only Windows device can take different paths to an IPv4-only service. An older application that opens an IPv4 socket uses WinCLAT and then NAT64. If an IPv6-capable browser receives a DNS64-synthesized AAAA record for the service and connects to that IPv6 address, it uses NAT64 without WinCLAT. Both connections reach the IPv4 destination, but only the first begins as IPv4 traffic on the client.

Where WinCLAT Does Not Help

WinCLAT is intended to provide outgoing IPv4 compatibility across an IPv6-only access network. It is not a substitute for native IPv4 on the local link. Applications that depend on IPv4 broadcast, multicast discovery, or direct access to an IPv4-only device on the same subnet may need a different solution. Protocols that embed IPv4 addresses or otherwise depend on behavior beyond ordinary translated unicast connections should also be tested individually.

Verify WinCLAT Operation

On a Windows 11 device where the feature is available, first verify that WinCLAT is permitted and inspect its global configuration.

netsh.exe interface clat show global

Next, inspect the interface-specific state, using the name of the connected interface.

netsh.exe interface clat show instance interface=<interface name>

Testing the WinCLAT Path

A successful connection to an IPv4-only website does not, by itself, demonstrate WinCLAT operation. An IPv6-capable browser may receive a DNS64-synthesized AAAA record and use NAT64 without WinCLAT. Test an application that explicitly uses an IPv4 socket or a literal IPv4 destination, then inspect the WinCLAT instance and capture traffic on the physical interface. The capture should show IPv6 traffic toward the NAT64 prefix for that connection.

Confirm Configuration and Traffic

Confirm that the interface has an IPv6 address configured using SLAAC and that WinCLAT has discovered a NAT64 prefix. The 192.0.0.1/32 address is used locally by WinCLAT and does not indicate native IPv4 connectivity. For that test, confirm the physical interface sends IPv6 traffic to the NAT64 prefix. Together, the configuration and packet capture provide stronger evidence of WinCLAT operation than either one alone.

Summary

WinCLAT is used when an eligible Windows interface operates without native IPv4 connectivity and an application generates IPv4 traffic. On an IPv6-only network, it gives IPv4 sockets and literal IPv4 addresses a path through NAT64. On an IPv6-mostly network, DHCPv4 option 108 can let a capable client forgo a native IPv4 lease and use the same translation path. Applications using native IPv6 or DNS64-synthesized AAAA records do not require WinCLAT. Successful deployment depends on SLAAC, NAT64, prefix discovery, and testing the applications that still require IPv4.

Additional Information

Microsoft Begins Rolling Out Windows CLAT (WinCLAT) for IPv6-Mostly and IPv6-Only Networks

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

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

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Note: For information about configuring the Citrix NetScaler to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IPRecently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.

Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.

Mitigation

To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.

Important Considerations

Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.

F5 BIG-IP Configuration

To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKI’s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Summary

Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Introduction

When preparing a DirectAccess server, an SSL certificate is required for the IP-HTTPS IPv6 transition technology. This certificate is often issued by a public Certification Authority (CA), but it can also be issued an organization’s internal Public Key Infrastructure (PKI).

SSL Certificate

Commonly an SSL certificate is issued for a single hostname, or subject. As long as the hostname matches the subject, everything works fine.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Multi-SAN SSL Certificate

To ease the management burden of using multiple certificates, or reduce the expense associated with using a wildcard certificate, organizations can request a multi-SAN (Subject Alternative Name) certificate, which matches more than one subject. The additional subjects are included in the Subject Alternative Name field on the SSL certificate.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS
A single multi-SAN certificate can be installed on multiple hosts and will work without issue as long as the hostname matches one of the SAN entries.

DirectAccess and Multi-SAN Certificates

When implementing DirectAccess in a multisite configuration, each entry point in the organization will have a unique public hostname. Instinctively, using a multi-SAN SSL certificate in this scenario would seem ideal.

Unfortunately, support for multi-SAN SSL certificates with DirectAccess is limited. To use a multi-SAN certificate for DirectAccess IP-HTTPS, the public hostname must match the name listed in the Subject field. In the example above, the subject is da.richardhicks.net, with SAN entries for da-west.richardhicks.net and da-east.richardhicks.net.

In this scenario, only the public name da.richardhicks.net is supported for use with DirectAccess. It will not work for any of the SAN entries. For example, attempting to configure DirectAccess to use this certificate with the public hostname da-west.richardhicks.net will fail with the following error message.

The subject name of certificate CN=[certificate subject name] is invalid.
Select a certificate with a valid subject name.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Attempting to work around this issue by using the Set-DAServer PowerShell cmdlet also fails to recognize the SSL certificate correctly.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Summary

Using a multi-SAN SSL certificate for the DirectAccess IP-HTTPS IPv6 transition technology is only supported when the public hostname matches the subject name of the certificate. Configuring DirectAccess with a public hostname listed in the SAN list is not supported. For multisite DirectAccess deployments, individual certificates must be issued for each entry point. Alternatively, a wildcard certificate can be used.