I recently joined Ed Horley and Tom Coffeen on the Packet Pushers IPv6 Buzz podcast episode 212 for a deep-dive discussion on Windows CLAT (WinCLAT). WinCLAT is now generally available. As the client-side component of 464XLAT, it lets IPv4-only applications keep working on IPv6-only networks, which removes one of the biggest obstacles to deploying IPv6-only and IPv6-mostly networks for Windows clients.
Episode Highlights
We covered a lot of ground in this episode, including the following.
How WinCLAT bridges the gap for IPv4 applications on IPv6-only networks
How WinCLAT lowers the barrier to IPv6 adoption
Configuring WinCLAT with PowerShell and Group Policy
Advanced troubleshooting techniques
Insights from WinCLAT telemetry
Listen or Watch Now
You can listen to IPB212: WinCLAT Deep Dive on the Packet Pushers website or watch the full episode below.
Accurate time is critical in an Active Directory environment. Kerberos authentication depends on it, and by default it tolerates no more than five minutes of clock skew between a client and a domain controller. Certificate validity periods, CRL publication, OCSP responses, and log correlation all depend on it too, which becomes even more important as organizations move to short-lived certificates. During a recent engagement to assess and remediate a customer’s Active Directory Certificate Services (AD CS) deployment, I noticed intermittent Kerberos authentication anomalies that didn’t line up with anything in the PKI itself. The root cause turned out to be time synchronization, which nobody had configured correctly across the domain. This post explains what I found and how I fixed it. I’ve reproduced the customer’s configuration in my lab, so the examples and output come from lab.richardhicks.net, but the process is the same one I used in the customer’s environment.
What I Found
When I reviewed time configuration across the customer’s domain, I found several problems, including the following.
Inconsistent domain controller configuration. Some domain controllers had never been configured and were still running the defaults. Others had been pointed manually at different external time sources, presumably by different administrators at different times. This resulted in more than one time root in the domain, which is exactly what the Windows time hierarchy is designed to prevent.
The PDC emulator was not authoritative. The domain controller holding the PDC emulator role had no external time source configured, so it wasn’t anchoring the domain to UTC.
Hyper-V was quietly providing the time. Most of the domain controllers were virtual machines running on Hyper-V. The Hyper-V time synchronization integration service (VMICTimeProvider) was enabled on all of them, and W32Time on the domain controllers was taking time from the host instead of the domain hierarchy.
The Hyper-V hosts had no time configuration at all. Most of the domain was running on Hyper-V hosts that were workgroup members. Workgroup machines don’t participate in the domain time hierarchy, and nobody had configured them. They were running on their own clocks, polling time.windows.com infrequently, if they could reach it at all.
The result was a loop with no anchor. The domain controllers took their time from the hosts, the hosts drifted on their own, and nothing in the environment was reliably tied to UTC. Different domain controllers on different hosts could disagree by a meaningful amount, which explained the inconsistent Kerberos behavior. In my lab, the PDC emulator showed the problem clearly.
PS C:\> w32tm.exe /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
...
ReferenceId: 0x564D5450 (source name: "VMTP")
...
Source: VM IC Time Synchronization Provider
Don’t be fooled by Stratum 1. The VM IC provider always reports Stratum 1, but the real source is the Hyper-V host’s clock. A quick comparison against a public time server showed the PDC emulator was about 840 milliseconds off UTC.
That’s not enough to break Kerberos on its own, but it was drifting, and in the customer’s environment, with multiple hosts and multiple time roots, the differences were much larger.
How Time Sync Should Work
Before making changes, it’s worth reviewing how Windows time synchronization is designed to work in an Active Directory domain. The hierarchy is simple and consists of the following.
The forest root PDC emulator is the authoritative time source. It is the only domain controller that should synchronize with an external source, and it advertises itself as a reliable time server (AnnounceFlags 5).
All other domain controllers follow the domain hierarchy. They use the NT5DS type and synchronize with the PDC emulator (directly or through their domain’s PDC emulator in a multi-domain forest). They advertise as time servers, but not as reliable ones (AnnounceFlags 10, the default).
Domain members synchronize with a domain controller. This is the default behavior for every domain-joined machine, although virtual machines need one adjustment, which I cover next.
Virtual Machines
Virtualization adds a wrinkle. On Hyper-V, the time synchronization integration service registers its own W32Time provider, VMICTimeProvider, which feeds the guest time from the host. It’s enabled by default on every virtual machine, and on a domain-joined VM it competes with the domain hierarchy and usually wins. Microsoft’s guidance is to disable VMICTimeProvider on virtual domain controllers so they get their time from the PDC emulator instead. I recommend disabling it on domain member VMs as well, so every domain-joined machine follows the same hierarchy.
Workgroup Hyper-V Hosts
The Hyper-V hosts matter too. If they’re domain members, they’ll follow the domain hierarchy automatically. If they’re workgroup members, as they were here, they need to be configured explicitly. Even with VMICTimeProvider disabled, the host’s clock still sets each VM’s time at startup and after a restore from a saved state, and the host needs accurate time for its own logs and certificates.
Target Configuration
The end state looks like this. The PDC emulator and the Hyper-V hosts both sync with the same public source, and every domain-joined machine, physical or virtual, follows the domain hierarchy.
System
Time source
Configured by
PDC emulator
time.cloudflare.com
DC Time Sync GPO
Other domain controllers
PDC emulator
DC Time Settings GPO
Domain members (physical and virtual)
Domain controllers
Domain Member Time Settings GPO
Hyper-V hosts (workgroup)
time.cloudflare.com
Local configuration
Resetting Domain Controllers to the Default Configuration
With domain controllers configured inconsistently, the cleanest approach is to return every one of them to the default configuration and then manage time centrally with Group Policy. Resetting first is important. Local settings remain in the registry underneath any policy, and if a domain controller ever stops receiving the policy (for example, after the PDC emulator role moves), it falls back to whatever was configured locally. Leftover manual peer settings would quietly create a second time root.
Restoring the Defaults
The following commands reset W32Time on every domain controller in the domain. They re-enable the Hyper-V time provider (the default), restore domain hierarchy synchronization, reset the peer list to the stock time.windows.com,0x9 value, and set AnnounceFlags back to 10 with /reliable:no.
I recommend this targeted approach over w32tm.exe /unregister and w32tm.exe /register. Re-registering the service rebuilds the entire W32Time configuration, but it can also remove the VMICTimeProvider subkey. That key is created by the Hyper-V integration components, not by W32Time, and it’s the key we’ll target with Group Policy in the next step.
Verifying the Reset
Next, confirm each domain controller is running the defaults and that no existing Group Policy is configuring W32Time.
Each domain controller should report Type: NT5DS (Local) and AnnounceFlags: 10 (Local), and the time policy check should return False. If it returns True, another GPO is already configuring W32Time. Find it and remove those settings before continuing. Don’t be surprised if the source still shows VM IC Time Synchronization Provider on some domain controllers at this point. That’s the default behavior we’re about to fix.
Configuring Time Sync with Group Policy
With every domain controller back to a known state, the next step is to configure time centrally with three GPOs. Two are linked to the Domain Controllers OU, and the third is linked to the domain root for domain members. The design includes the following.
GPO
Applies to
Settings
DC Time Settings
All domain controllers
Type NT5DS, AnnounceFlags 10, NTP client and server enabled, VMICTimeProvider disabled
DC Time Sync
PDC emulator only (WMI filter)
Type NTP, NtpServer time.cloudflare.com,0x8 time.nist.gov,0xa, AnnounceFlags 5
Domain Member Time Settings
All domain members (linked to the domain root)
VMICTimeProvider disabled
DC Time Sync is linked with a higher precedence (link order 1), so on the PDC emulator its values override the baseline from DC Time Settings. Every other domain controller receives only the baseline. A nice benefit of this design is that it follows the PDC emulator role automatically. If the role moves to another domain controller, the WMI filter matches the new role holder, and the old one falls back to the baseline with no administrator intervention. However, if the PDC emulator role moves to another DC, don’t forget to update the outbound access rules on the edge firewall to allow the new server to access the public time resource.
Choosing a Time Source
I used time.cloudflare.com as the primary time source for this customer, with time.nist.gov as a fallback. You can use any reliable public time service, such as time.windows.com or a regional pool.ntp.org address. Separate multiple servers with spaces in the NtpServer value.
Adding a Fallback Time Source
A single upstream time source works, but it makes the entire domain dependent on one provider. Microsoft recommends configuring three or more time servers when using multiple peers, or, with only two, marking one with the UseAsFallbackOnly flag (0x2). I chose the latter, setting NtpServer to time.cloudflare.com,0x8 time.nist.gov,0xa. The 0xa flag combines client mode (0x8) and fallback only (0x2), so W32Time uses NIST only when Cloudflare is unavailable. Keep the following in mind when choosing a fallback.
It removes a single point of failure. Cloudflare’s time service is highly reliable, but the service itself isn’t the only thing that can fail. A DNS resolution failure, a BGP route leak or hijack affecting the provider’s prefixes, an upstream ISP routing problem, or a firewall change can all make a single provider unreachable from your network. NIST runs on a completely separate network and doesn’t use anycast, so an event that affects one provider is unlikely to affect the other.
An outage isn’t catastrophic. Even if the PDC emulator can’t reach any upstream source, it keeps running on its own clock and continues serving time to the rest of the domain. Every domain controller and domain member still follows the PDC emulator, so the domain stays in sync with itself while slowly drifting from UTC. That’s what matters most for Kerberos, which compares the client’s clock with the domain controller’s clock, not with UTC. A typical system clock drifts by a few seconds per day at most, so an outage lasting hours or even days has no practical impact. When the time source becomes reachable again, W32Time corrects the accumulated offset automatically.
Both sources must handle leap seconds the same way. Cloudflare and NIST both insert leap seconds as a one-second step, so they’re a safe pair. Google, AWS, and Meta smear leap seconds instead, so don’t pair one of them with Cloudflare or NIST. The next section explains why.
A fallback doesn’t improve accuracy. A second source improves availability, not accuracy. With UseAsFallbackOnly, W32Time only consults NIST when Cloudflare is unreachable, so there’s nothing to cross-check against. Even with two active peers, there’s no majority to decide which one is right if they disagree. That’s fine for a typical Active Directory domain, which doesn’t require high-accuracy time.
Leap Second Considerations
Avoid mixing time services that handle leap seconds differently. A leap second is an occasional one-second adjustment to UTC that keeps it aligned with the Earth’s rotation. Most time services, including Cloudflare and NIST, apply it the standard way, by inserting the extra second all at once. Google (and AWS) instead “smear” it by slightly slowing their clocks over a 24-hour window, so during that period their time differs from other services by up to half a second. If a domain controller has both kinds of servers in its peer list, they disagree during a leap event, and the results are unpredictable. Pick one approach and use it consistently. You can read more about each approach in Google’s leap smear documentation and Cloudflare’s NTP documentation.
Allowing Outbound NTP
The PDC emulator must be able to reach both time services on UDP port 123. In the customer’s environment, as in my lab, outbound NTP was blocked at the edge firewall. I added a rule allowing outbound UDP 123 from the PDC emulator to the IPv4 and IPv6 addresses of both time services. Cloudflare publishes its addresses in its documentation, and NIST publishes the list of servers that time.nist.gov rotates across. Be sure to include both address families if your domain controllers have IPv6 connectivity, because W32Time will often prefer IPv6 when the name resolves to both. Also, remember to update the rule if the PDC emulator role moves to a different server. You can validate reachability to both services from the PDC emulator before configuring anything.
If both return offsets, you’re good to go. An error of 0x800705B4 indicates a timeout, which usually means UDP 123 is blocked or the IPv6 path isn’t working.
Creating the GPOs
The following script creates the WMI filter and all three GPOs. It links the two domain controller GPOs to the Domain Controllers OU and the member GPO to the domain root. It requires the GroupPolicy and ActiveDirectory modules (Install-WindowsFeature -Name GPMC, RSAT-AD-PowerShell on Windows Server) and Domain Admin rights. Run it in Windows PowerShell 5.1. You can also download the script from GitHub.
$MemberGpo =New-GPO -Name 'Domain Member Time Settings'-Comment 'Disable the Hyper-V time provider so domain members follow the domain hierarchy'-Server $Pdc
There are a few things worth noting about this script.
Everything targets the PDC emulator. The GroupPolicy cmdlets talk to the PDC emulator by default, but the ActiveDirectory cmdlets can pick any domain controller. Without -Server, Set-ADObject may land on a domain controller where the new GPO hasn’t replicated yet, and the script fails partway through. I hit this in the field, so the script now pins every call to the PDC emulator.
Only the required values are written. Enabling the Global Configuration Settings Administrative Template writes every value it contains, including some outdated clock discipline defaults. Setting individual registry values avoids that, and everything not set by policy keeps its default. The trade-off is that GPMC may show these under Extra Registry Settings instead of Windows Time Service. That’s cosmetic.
VMICTimeProvider is disabled with a preference, not a policy. There is no Administrative Template setting for it. The Group Policy Preference writes directly to the service key, so it persists even if the GPO stops applying, which is what you want for a domain controller.
The member GPO needs only the preference. Domain members already default to NT5DS, so VMICTimeProvider is the only thing keeping virtual machines off the domain hierarchy. Because it’s linked to the domain root, it also applies to domain controllers. That’s harmless, since DC Time Settings sets the same value and takes precedence.
The WMI filter is assigned directly. The GroupPolicy module has no cmdlet for creating or assigning WMI filters, so the script writes the gPCWQLFilter attribute itself.
Multi-domain forests.DomainRole = 5 matches the PDC emulator of any domain. Link DC Time Sync only in the forest root domain. Child domain PDC emulators should follow the domain hierarchy.
GPOs applied to domain controllers.
DC Time Sync GPO with WMI filtering applied to PDC emulator.
Applying the Policies
Force replication so every domain controller has the new GPOs, then apply them and restart the time service.
Domain members pick up the new GPO at their next policy refresh. However, W32Time reads which providers are enabled only when the service starts, so a member VM keeps using VMICTimeProvider until W32Time restarts or the machine reboots. To switch a member over immediately, run the following commands on it.
gpupdate.exe /target:computer /force
Restart-Service -Name W32Time
w32tm.exe /resync /rediscover
Configuring the Workgroup Hyper-V Hosts
With the domain controllers fixed, the last piece is the Hyper-V hosts. In the customer’s environment, most of the domain ran on hosts that were workgroup members, and none had any time configuration. The VMs no longer take their time from the host continuously, but the host’s clock still sets each VM’s time at startup and after a restore from a saved state. Workgroup machines don’t participate in the domain hierarchy, so Group Policy can’t help here. Each host must be configured locally, and there are two reasonable options.
Sync directly from the public time service. This is what I did for the customer. The hosts don’t depend on a VM they’re running, which avoids a chicken-and-egg problem at boot. It does require allowing outbound UDP 123 from each host.
Sync from the PDC emulator. This keeps a single internal source of truth and needs no additional edge firewall rules, since domain controllers answer NTP requests by default. The downside is that the host boots before the PDC emulator VM and runs on its own clock until the domain controller is available.
Either way, everything traces back to the same UTC source. Run the following commands locally on each Hyper-V host.
Setting SpecialPollInterval is important. The workgroup default is 604,800 seconds, or one week, which is far too infrequent to keep a virtualization host accurate. The 0xb flag on time.nist.gov adds fallback only (0x2) to the same flags, so the hosts follow the same primary and fallback design as the PDC emulator. To sync from the PDC emulator instead, replace the peer list with the PDC emulator’s name or IP address, and optionally add another domain controller with the 0xb flag as a fallback. Use IP addresses if the hosts don’t use the domain’s DNS servers.
Domain Member Virtual Machines
VMICTimeProvider is enabled by default on every Hyper-V VM, not just domain controllers, so domain-joined member VMs take their time from the host instead of the domain hierarchy. With accurate hosts, that works, but it creates a second time root. Domain controllers follow the PDC emulator, while member VMs follow whichever host they run on. In my lab, a member VM was about 77 milliseconds off the PDC emulator, even though both its host and the PDC emulator synced with Cloudflare. If a host loses access to its time source, its VMs drift away from the domain controllers, which is the original problem in a new place. The Domain Member Time Settings GPO prevents this. It disables only the W32Time provider, not the Hyper-V time synchronization integration service, so VMs still get their clock set at startup and after a restore from a saved state.
Validating the Configuration
Once everything is in place, confirm each tier of the hierarchy is getting time from the right place, including the domain controllers, domain members, the Hyper-V hosts, and the domain as a whole.
Validating Domain Controllers
Run the following commands to check the time configuration and status of every domain controller.
Validating domain controller time configuration settings.
The .Line.Trim() is there for a reason. Select-String results returned through Invoke-Command are deserialized objects that PowerShell can’t format, so without it you’ll see blank lines instead of the output. The following table shows what to look for on each type of server.
Server
Type
AnnounceFlags
Source
Stratum
VMICTimeProvider
PDC emulator
NTP (Policy)
5 (Policy)
time.cloudflare.com,0x8
4
0
Other domain controllers
NT5DS (Policy)
10 (Policy)
PDC emulator
5
0
Hyper-V hosts
NTP (Local)
n/a
time.cloudflare.com,0x9
4
n/a
The (Policy) label confirms Group Policy is in control rather than local settings. Root Dispersion will be high immediately after the service restarts and should settle under a second within about 30 minutes. NtpServer lists both time services, but the source should show time.cloudflare.com. If it shows time.nist.gov, the PDC emulator can’t reach Cloudflare and has switched to the fallback.
Validating Domain Members
On a domain member VM, run the following commands to confirm it follows the domain hierarchy and agrees with the PDC emulator.
Domain member VM synchronizing with the PDC emulator.
The source should be a domain controller, not VM IC Time Synchronization Provider, and the stratum should be one or two levels below the PDC emulator. In my lab, a member VM went from about 77 milliseconds off the PDC emulator to under 10 milliseconds within minutes of switching to the domain hierarchy.
Validating Hyper-V Hosts
On the Hyper-V hosts, run the following commands locally.
Time synchronization settings on the Hyper-V host server.
Both time services are listed as peers. The State for time.cloudflare.com should be Active. A state of Pending that persists usually means the host can’t reach that time server. However, Pending is also normal for up to one polling interval after the service restarts, which is about 17 minutes with a SpecialPollInterval of 1024 seconds, because W32Time rebuilds its peer list and resets the peer statistics. To tell the difference, run w32tm.exe /query /peers /verbose and check LastSyncError. A value of 0x00000000 (Succeeded) means the last sync worked, and the peer will return to Active at its next poll.
Validating the Domain
After things have had time to settle, check the entire domain at once. Every domain controller should show a small offset relative to the PDC emulator, with no errors.
w32tm.exe /monitor /domain:$DomainFqdn
All domain controllers synchronizing with the PDC emulator.
You might notice an unusual IPv4 address listed for dc1, such as 36.113.118.130. That’s not dc1’s address, and it’s not a real IPv4 address at all. It’s the RefID, which identifies the server’s upstream time source. The NTP reference ID field is only 32 bits, so when the source is reached over IPv6, as time.cloudflare.com is here, the field contains the first 32 bits of the MD5 hash of the source’s IPv6 address, as defined in RFC 5905. It’s expected behavior and can safely be ignored. In my lab, the PDC emulator went from roughly 840 milliseconds off UTC to closely tracking UTC once it began syncing with Cloudflare. In the customer’s environment, the Kerberos anomalies stopped once all domain controllers and hosts converged on a single source.
Summary
Time synchronization is easy to overlook, especially in virtualized environments where Hyper-V quietly fills in the gaps. In this case, the symptoms showed up as Kerberos anomalies during an AD CS engagement, but the root cause was a domain with no single, authoritative time source. The fix came down to the following steps.
Reset every domain controller to the default W32Time configuration.
Configure the PDC emulator, and only the PDC emulator, to sync with a reliable public time service, plus a second as a fallback, using a WMI-filtered GPO.
Configure all other domain controllers to follow the domain hierarchy and disable VMICTimeProvider on every domain controller with a second GPO.
Disable VMICTimeProvider on domain members with a third GPO linked to the domain root, so virtual machines follow the domain hierarchy too.
Allow outbound UDP 123 for the systems that sync externally.
Explicitly configure any workgroup Hyper-V hosts, since they don’t participate in the domain hierarchy.
With Group Policy managing the domain controllers and domain members, the configuration is consistent, self-documenting, and follows the PDC emulator role automatically if it ever moves.
Microsoft released the November 2026 security updates today, which include three vulnerabilities affecting Always On VPN deployments. This month’s release addresses issues in the Secure Socket Tunneling Protocol (SSTP) and Internet Key Exchange (IKE). And for a change, there are NO vulnerabilities in the Windows Server Routing and Remote Access Service (RRAS) this month!
SSTP Vulnerabilities
SSTP is commonly used for Always On VPN user tunnel connections. Because SSTP is, by design, exposed directly to the Internet, vulnerabilities affecting this protocol deserve attention. This month’s updates address the following two SSTP vulnerabilities. Both are rated Important.
The November 2026 security updates also address a spoofing vulnerability in the Windows IKE Extension. Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected. Microsoft rates this vulnerability as Important.
RRAS has been a regular fixture in the monthly security updates, with several CVEs disclosed in most recent releases. September 2026 alone included eight RRAS CVEs, four of them rated Critical. It is refreshing to report that the November 2026 release includes no RRAS vulnerabilities at all.
Summary
This is a relatively light month for Always On VPN administrators. All three vulnerabilities are rated Important, and none are rated Critical. However, SSTP and IKE are both Internet-facing services in most Always On VPN deployments, so administrators should plan to deploy these updates during their next scheduled maintenance window and avoid unnecessary delays.
This release introduces new capabilities for monitoring connector performance and resolving names in complex network environments, including the following.
Performance and Diagnostics
The Connector Diagnostics tool, available from the system tray, now includes a new Performance tab. Here, administrators can view up to 24 hours of resource history for the connector server, collected in one-minute aggregates. The Performance tab displays average and peak values for the following metrics.
Machine CPU: Total CPU usage across the machine.
Connector CPU: Share of total machine CPU used by the connector.
Connector resident memory: Physical memory used by the connector process.
Machine available memory: Physical memory still available to applications.
Administrators can use the Window drop-down list to display performance history for the last 1 hour, 6 hours, or 24 hours. This gives better visibility into resource consumption over time, which is helpful when sizing connector servers or investigating performance issues. In addition, this update improves the accuracy of connector health reporting.
DNS Resolution
The connector now honors DNS suffixes and DNS servers configured on individual network interfaces in Windows. This update also improves the fallback behavior for DNS SRV record queries.
Improvements
In addition to new features, v1.5.5130.0 includes several improvements to logging, reliability, and security.
Logging and Observability
This update includes the following changes to connector logging.
Trace file rotation is now supported.
The default capacity for the Session event log has been increased to 3 GB.
Error messages for connectivity and backend failures have been improved to streamline troubleshooting.
Note: With the larger default Session event log size, administrators should ensure the connector server has sufficient free disk space on the system drive.
Reliability and Security
This update also includes the following reliability and security enhancements.
TCP keepalive has been added to reduce idle connection resets.
Memory management during request processing has been improved.
Security for local log files and other connector files has been enhanced.
Updating to v1.5.5130.0
Existing Entra Private Network Connector installations will not automatically receive this update. Administrators must manually download the connector from the Microsoft Entra admin center and apply the update themselves to take advantage of these new features and capabilities.
Windows CLAT (WinCLAT) allows IPv4 applications to reach IPv4 destinations on IPv6-only and IPv6-mostly networks. Windows does not permit WinCLAT on Wi-Fi or Ethernet by default, and Microsoft Intune does not currently expose a setting to permit it. This post explains how to deploy the permit setting with Intune Remediations, verify that WinCLAT is translating, and maintain connectivity to Intune when removing the setting.
WinCLAT Configuration Options in Intune
At the time of this writing, Intune does not expose WinCLAT configuration settings in the Settings Catalog or through a CSP. The corresponding Group Policy settings are defined in the built-in Windows template tcpip.admx. However, Intune’s custom ADMX import feature is intended for third-party and custom templates. Microsoft explicitly advises against importing built-in Windows ADMX files when the goal is to configure those settings, recommending the Settings Catalog or a custom profile instead.
Configuring WinCLAT with Remediations
An Intune Remediation can write the same registry value that Group Policy uses to permit WinCLAT on non-cellular interfaces. Windows reads that value as policy and gives it precedence over the local permit setting. If Group Policy already configures the setting on a device, continue managing it through Group Policy, since a policy refresh can overwrite the value written by the remediation script.
Deployment Requirements
Before deploying the Remediation, confirm that clients meet the following connectivity, platform, and licensing requirements.
Intune Connectivity Before WinCLAT Starts
The Intune Management Extension must be able to reach the endpoints it uses to retrieve the script package before WinCLAT starts. Native IPv4 provides that path on dual-stack networks and on IPv6-mostly networks where Windows still has a DHCPv4 lease. On an IPv6-only network, DNS64 and NAT64 can provide access to IPv4-only Intune endpoints by name. If the target network has no working path to the required endpoints before WinCLAT starts, deploy the package from a network that does. After deployment, verify that the device can still check in with Intune from the target network.
Network
Path to Intune before WinCLAT is enabled
Expected delivery path available?
Dual-stack
Native IPv4
Yes
IPv6-mostly (DHCPv4 option 108)
Native IPv4. While WinCLAT is not permitted, Windows does not honor option 108 and takes a DHCPv4 lease
Yes
IPv6-only with DNS64/NAT64
DNS64 and NAT64
Yes
IPv6-only without DNS64/NAT64
No path to required IPv4-only endpoints in this scenario
No
Windows and Intune Prerequisites
Devices must run Windows 11 version 25H2 build 26200.9550 or later, be Microsoft Entra joined or Microsoft Entra hybrid joined, and be enrolled in Intune or co-managed. Verify that device users have a qualifying license, such as Windows Enterprise E3 or E5, and that the Intune Management Extension is installed before running the package on demand.
WinCLAT Policy Settings
The WinCLAT Group Policy settings are in tcpip.admx under Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies, and they are stored as DWORD values in the following location.
Discovers the NAT64 prefix from the PREF64 option in router advertisements
GetPrefixInfoFromDNS
pref64fromdns
Pref64FromDns
Discovers the NAT64 prefix by querying ipv4only.arpa against a DNS64 server
Interpreting WinCLAT Policy Values
Each policy value is a REG_DWORD. A value of 1 enables the setting, and a value of 0 disables it. Deleting the value returns control to the local setting. Windows allows NAT64 prefix discovery through both router advertisements and DNS by default, so the scripts in this post manage only PermitNonCellularCLAT.
Deploying the WinCLAT Remediation
Detect-WinClatPermitPolicy.ps1 compares PermitNonCellularCLAT with the desired registry state. It returns exit code 0 when the state matches and 1 when a change is needed. When detection returns 1, Intune runs Remediate-WinClatPermitPolicy.ps1 to write or remove the policy value.
Setting the Desired Policy State
Both scripts begin with a $DesiredState variable that corresponds to the three states of the Group Policy setting. Remediations do not accept parameters, so set the variable to the same value in both scripts before uploading them and create a separate Remediation for each state that is needed, such as Enable WinCLAT and Remove WinCLAT Policy.
# Enabled, Disabled, or NotConfigured. Must match the remediation script.
$DesiredState = 'Enabled'
Desired state
Registry value
Result
Enabled
1
WinCLAT is permitted, and the setting is under policy control
Disabled
0
WinCLAT is not permitted, and the setting is under policy control
NotConfigured
Deleted, along with the IPxlatCfgSvc key if it is then empty
Go to Devices > Manage devices > Scripts and remediations, then select Create script package.
Enter a name, such as Enable WinCLAT, and upload the detection and remediation scripts with $DesiredState set to Enabled.
Configure the following settings:
Run this script using the logged-on credentials: No. The scripts write to HKLM and must run as SYSTEM.
Enforce script signature check: No, unless the scripts are signed.
Run script in 64-bit PowerShell: Yes.
Assign the Remediation to a group of devices and choose a schedule. An hourly or daily schedule keeps the value in place if it is removed.
Intune Remediation script configuration settings.
Testing the Remediation on a Single Device
To test the package, open the device’s Overview page in the Intune admin center, select Run remediation, and choose the WinCLAT script package. You can run the package on demand without assigning it to the device. The device must be online, have the Intune Management Extension installed, and be able to communicate with Intune and the Windows Push Notification Service (WNS).
Run Remediation interactively on a specific endpoint.
Reviewing Remediation Results in Intune
On the device page in the Intune admin center, select Remediations to review the script package results. In the example below, With issues indicates that the registry state differed from the desired state, and Issue fixed indicates that the script corrected it. Verify the effective permit setting and translation state separately on the client.
Remediation results.
WinCLAT Activation After Remediation
Applying the permit policy allows Windows to start WinCLAT automatically on eligible interfaces. What happens next depends on whether the interface already has a native IPv4 address and whether Windows can discover a NAT64 prefix.
IPv6-Only Networks
On an IPv6-only test network, WinCLAT begins translating about a minute after the script writes the permit value, without a reboot, Group Policy refresh, or service restart. The instance uses an address from the IPv4 Service Continuity Prefix (RFC 7335), typically 192.0.0.1. Automatic activation requires an eligible interface with a Stateless Address Autoconfiguration (SLAAC) address, a discoverable NAT64 prefix, and autoenable enabled. The policy value persists across reboots.
IPv6-Mostly Networks
On an IPv6-mostly network, Windows already has a DHCPv4 lease when the remediation runs. Neither applying the permit policy nor running ipconfig /renew releases the existing lease. After the adapter restarts, Windows honors DHCPv4 option 108 (IPv6-Only Preferred), comes up without a native IPv4 address, and starts translating within seconds. For a production rollout, let devices reconnect normally or restart the target adapter during a maintenance window. Restarting it interrupts connectivity.
WinCLAT Activation Events
Use the Microsoft-Windows-IPxlatCfg/Operational log to verify that WinCLAT started. Event 1106 (Instance enabled) records why Windows enabled the instance, and Get-WinClatInstance reports that reason in TriggerSource when the event is available. When a new instance starts translating, event 1106 is typically followed by event 1108 (Remote prefix discovered) and event 1109 (Translation started). For more on event 1106 and how to identify the associated network adapter, see Understanding Windows CLAT (WinCLAT) Event Logging.
Event 1109 shows that WinCLAT began translating.
Verifying Policy and Translation
Verify the effective permit setting first, then check whether WinCLAT is translating on the target interface. Use netsh.exe or the WinCLAT PowerShell module for both checks.
Verifying the Effective Permit Setting
Run netsh.exe interface clat show global store=both or Get-WinClatConfiguration -Store Both to compare the active and persistent stores. The active store shows the effective configuration, and the persistent store shows the saved local configuration. In this example, policy enables permit in the active store while the local setting remains disabled. Use the module’s PolicyControlled property to confirm that policy controls Permit, even when both stores report the same value.
Output of netsh.exe interface clat show global store=both.
Get-WinClatConfiguration -Store Both | Format-List
Output of Get-WinClatConfiguration -Store Both.
Verifying Translation on an Interface
From an elevated command window, run netsh.exe interface clat show instance interface=<index> using the interface index from Get-NetAdapter, and look for Is translating : yes. Alternatively, run Get-WinClatInstance and look for IsTranslating : True on the target interface. The module lists active adapters with IPv6 enabled, so you can run it without supplying an interface index. To verify end-to-end connectivity, test an IPv4-only application or connect to a literal IPv4 address from the target network.
Output of netsh.exe interface clat show instance.
Output of Get-WinClatInstance.
Removing the WinCLAT Policy
Unassigning the enablement package leaves the policy value in the registry. To restore local control, create a removal package using the same scripts with $DesiredState set to NotConfigured. Use Disabled when you want policy to enforce a disabled permit setting.
Maintaining Intune Connectivity During Removal
Before removing the policy, confirm that the device will still be able to reach Intune if automatic WinCLAT translation stops. A device that relies on WinCLAT to reach IPv4-only Intune endpoints can lose its ability to report the result or receive a recovery package. Use a network with a working path to Intune through native IPv4 or DNS64 and NAT64. On an IPv6-mostly network, check whether the device has a native IPv4 address after removal. Reconnect the adapter if it needs to obtain a new DHCPv4 lease.
Replacing the Enablement Assignment
Before assigning the Remove WinCLAT Policy package, remove the target devices from the enablement assignment. Use a pilot device to confirm that it has received the assignment change and that the enablement package no longer runs on it. After the target devices report successful removal, you can assign the removal package more broadly.
Verifying Policy Removal
Run Get-WinClatConfiguration and confirm that PolicyControlled no longer lists Permit. The effective Permit value should now match the local setting, which is disabled by default. If removal stops an automatically enabled instance, Get-WinClatInstance should report IsTranslating : False for that interface. The operational log may also show event 1110 (Translation stopped) and event 1107 (Instance disabled).
Event 1107 shows that Windows disabled the WinCLAT instance on the interface.
Get-WinClatConfiguration shows Permit=False and an empty PolicyControlled field.
Get-WinClatInstance shows IsTranslating=False.
Limits of Registry-Based Management
The script packages manage the WinCLAT permit policy. Automatic activation, manually enabled instances, and local changes to policy-controlled settings require separate checks.
Automatic Activation
The autoenable setting is enabled by default and has no corresponding WinCLAT Group Policy setting. If an administrator has disabled it, setting PermitNonCellularCLAT to 1 permits WinCLAT but leaves automatic activation disabled. To restore automatic activation, use netsh.exe interface clat set global autoenable=enabled or Set-WinClatConfiguration -AutoEnable Enabled.
Manually Enabled Instances
Disabling Permit stops automatically enabled instances. A manually enabled instance can continue translating until you disable it explicitly or the device reboots. Check the instance state on the target interface if your objective is to stop translation.
Local Changes to Policy-Controlled Settings
When policy controls a WinCLAT setting, netsh.exe interface clat set global can report success and update the local value in the persistent store while the active value continues to follow policy. Use netsh.exe interface clat show global store=active to verify the effective value. If you use Set-WinClatConfiguration to request a value that differs from the effective policy value, the cmdlet reports PolicyOverride.
Using netsh.exe in a Remediation
A Remediation can also run netsh.exe to configure WinCLAT, and this is the only way to enforce autoenable. However, netsh.exe changes the local configuration rather than policy, and reliable detection requires parsing localized command output, so this approach is outside the scope of this post.
Summary
Intune Remediations can deploy and remove the WinCLAT permit policy on Windows 11. Make sure devices can reach Intune before deployment, then verify the effective policy and translation state on the target interface. On IPv6-mostly networks, devices with an existing DHCPv4 lease may need to reconnect before Windows uses WinCLAT. Before removing the policy, confirm that devices will still have a working path to Intune.
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.
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.
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.
Right-click Custom Views and choose Import Custom View.
Select the winclat-event.xml file downloaded previously and click Open.
Review the Name and Description of the Custom View and click OK.
Click OK.
WinCLAT events displayed in an Event Viewer custom view.
WinCLAT Event ID Reference
The following table shows the WinCLAT event IDs.
Event ID
Description
When it is recorded
1106
Instance enabled
CLAT is enabled on an interface, automatically or manually
1107
Instance disabled
CLAT is disabled on an interface
1108
Remote prefix discovered
CLAT discovers the NAT64 prefix for an interface
1109
Translation started
CLAT begins translating on an interface
1110
Translation stopped
CLAT stops translating on an interface
1111
CLAT IPv6 address DAD failure
The 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.
Code
Trigger source
Meaning
1
Pref64 RA
Enabled automatically because the network’s router advertisements include the PREF64 option
3
No IPv4
Enabled automatically because the interface has no IPv4 connectivity
5
Manual
Enabled 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.
@{ 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.
Windows CLAT (WinCLAT) allows applications that use IPv4 sockets or literal IPv4 addresses to continue working on IPv6-only and IPv6-mostly networks by translating their IPv4 traffic to IPv6 for delivery to a NAT64 gateway. For administrators planning an IPv6-only deployment, this raises an obvious question: which applications still depend on IPv4 and are using WinCLAT?
Application Visibility
WinCLAT’s built-in logging does not identify the applications using it. This post explains how to use Microsoft SysinternalsSysmon to record the executable, user account, and destination associated with IPv4 connections that use the WinCLAT source address. It also describes the filtering requirements and limitations of this approach. The behavior described applies to Sysmon 15.22. Later versions may differ.
What WinCLAT Logs
WinCLAT records events in the Microsoft-Windows-IPxlatCfg/Operational event log, but those events describe the WinCLAT instance on each interface, not the traffic passing through it.
Event ID
Description
1106
Instance enabled
1107
Instance disabled
1108
Remote prefix discovered
1109
Translation started
1110
Translation stopped
1111
WinCLAT IPv6 address DAD failure
No event identifies the application that used WinCLAT or the destination it connected to. The netsh.exe interface clat commands report the same kind of instance and configuration state. As a result, WinCLAT can translate traffic on an interface with no built-in record of what generated it.
Logging WinCLAT Connections with Sysmon
Sysmon is a Microsoft Sysinternals tool that runs as a Windows service and logs detailed system activity, including process creation, network connections, and file changes, to the Windows Event Log. Sysmon can be configured specifically to log network traffic generated by WinCLAT.
Identifying WinCLAT Traffic in Event ID 3
Sysmon Event ID 3 (Network connection) logs TCP and UDP connections and links each one to a process. When an application uses WinCLAT, its socket is still an IPv4 socket, so the event shows the application’s IPv4 addresses rather than the translated IPv6 addresses:
Calling executable and account – Image, ProcessId, ProcessGuid, and User
Destination – DestinationIp, DestinationPort, and Protocol
WinCLAT source address – SourceIp
The source address is what makes this useful. While WinCLAT is active, it assigns the interface an IPv4 address from the IPv4 Service Continuity Prefix192.0.0.0/29 (RFC 7335), typically 192.0.0.1. Filtering on that source separates traffic that uses WinCLAT from other network activity. Traffic that uses a native IPv4 route has a different source address, and traffic from applications that use IPv6 directly, including through DNS64 and NAT64, is not IPv4 traffic and does not match.
Preparing the WinCLAT Filter
Network connection events are disabled by default, so Sysmon requires a configuration file to enable them. Save the following as sysmon-winclat.xml, or download it from GitHub here.
Includes connections with a source address in the WinCLAT range. A computer with several translating interfaces uses a different address on each one.
Excludes multicast and broadcast destinations, and destinations in the WinCLAT range itself. Local protocols such as LLMNR and NetBIOS can use the WinCLAT IPv4 address, but this traffic is not destined for NAT64. A source address in the WinCLAT range therefore does not by itself prove that a packet was translated.
Disables reverse DNS lookups with DnsLookup. A reverse lookup would add unnecessary queries, and its result would not show the name the application requested anyway.
Turns off other default event types with empty include rules. Without these rules, Sysmon also logs events such as process creation and termination, which are unrelated to WinCLAT and can far outnumber the network connection events. Sysmon still logs its service state and configuration change events, which cannot be filtered.
Turning off process creation events removes the command line and parent process from the log. To keep that context for investigations, remove the ProcessCreate rule and accept the additional volume. See the Sysmon documentation for more filtering options.
This query includes all retained Event ID 3 records, including events collected before the WinCLAT configuration was applied.
Unique application and user account combinations recorded by Sysmon.
To report across many computers, collect the events centrally with Windows Event Forwarding or a SIEM agent.
Interpreting the Results
Sysmon Event ID 3 records different information depending on the protocol and whether the connection succeeds. The table below shows which types of traffic can produce an event and what each record tells you about the connection.
Traffic through WinCLAT
Recorded by Event ID 3
What an event means
TCP connection
Yes
The connection was established
TCP attempt with no response
May not be recorded
Not applicable
UDP
Yes, with or without a reply
The application attempted to send, not that the traffic was delivered
ICMP
No
Not applicable
Limitations of Event ID 3
Use these events to identify which processes communicate with IPv4 destinations. When reviewing the results, keep in mind that some activity may be missing and that the recorded fields provide limited information about the application’s behavior.
ICMP is not recorded. Event ID 3 covers TCP and UDP only, so ping to an IPv4 address leaves no event.
Failed TCP attempts can be missed. An application that repeatedly tries to reach an unresponsive IPv4 address may not appear in the log. This matters because unreachable destinations through WinCLAT time out rather than failing immediately.
Events show WinCLAT use, not literal use. An application that resolves a name to an IPv4 address and connects with an IPv4 socket produces the same event as an application that uses a literal IPv4 address. The destination is the resolved address in both cases, so Sysmon cannot confirm that an address is hard-coded. Sysmon Event ID 22 (DNS query) can provide supporting context, because it identifies the process that made a query, but the absence of a matching query is not proof of a literal. The configuration above does not log this event, so collecting it requires adding a DnsQuery rule.
Event counts are not traffic counts. Sysmon does not record one event per packet or per flow, so several UDP sends on one socket can produce a different number of events. Use the events to identify which applications communicate with which destinations, not to measure traffic volume.
Shared processes hide the service. Traffic from a Windows service can appear with an Image of svchost.exe. Use the ProcessId to identify the service while the process is still running.
Native IPv4 is excluded. On a computer with native IPv4 connectivity, some connections may use a native IPv4 source address instead of the WinCLAT source address. Those connections do not match this filter and are not included in the results.
Additional Troubleshooting Tools
If traffic that Sysmon does not record becomes important, such as ICMP or failed connection attempts, the following sources may help. Each has its own trade-offs, so evaluate them in your environment.
Windows Filtering Platform auditing. The Filtering Platform Connection audit subcategory records permitted and blocked connections in the Security event log as events 5156 and 5157, including the application where available. It can generate a high volume of events.
Packet capture. A capture on the physical adapter with a tool such as pktmon.exe can show translated IPv6 traffic, including ICMP and unanswered connection attempts. The IPv4 destination is embedded in the destination address under the NAT64 prefix. Packet headers alone do not identify the calling executable, so process attribution requires additional correlation.
NAT64 gateway logs. Depending on the gateway, its logs can show the client and destination of translated traffic, but not the application.
Summary
WinCLAT logs instance state changes but does not identify the applications using it. Sysmon Event ID 3, filtered on WinCLAT source addresses and with common local traffic excluded, provides a practical way to identify applications likely using WinCLAT. The events record the executable, user account, destination address, and port for matching TCP and UDP connections. They do not cover ICMP, may omit failed TCP attempts, and cannot distinguish a literal IPv4 address from an address obtained through name resolution. Use the results to identify applications for further investigation and confirm translation with a packet capture when needed.
Windows CLAT (WinCLAT) is generally available on Windows 11 25H2, starting with build 26200.9550. WinCLAT is the Windows client-side translator for 464XLAT (RFC 6877). It translates IPv4 traffic from applications into IPv6 for delivery to a NAT64 gateway, allowing IPv4-only applications to continue working on IPv6-only and IPv6-mostly networks. Successful operation depends on both the Windows client configuration and the supporting network infrastructure. This post explains how to use the WinCLAT PowerShell module to verify these requirements, diagnose common problems, and test IPv4 connectivity through the translation path.
Why Use the WinCLAT PowerShell Module
WinCLAT is configured and inspected using the netsh.exe interface clat command context. However, its output requires careful interpretation when troubleshooting. A configuration command can complete without error even when Group Policy prevents the requested setting from taking effect. An instance can report that it is translating while IPv4 traffic fails, and disabling a global setting does not necessarily stop a manually enabled instance. The WinCLAT PowerShell module simplifies these tasks by checking the effective configuration after changes and providing health checks with explanations and recommended corrective actions. It supports troubleshooting on individual computers and across multiple remote computers.
How WinCLAT Activates
Understanding when WinCLAT activates automatically helps explain many troubleshooting scenarios. With AutoEnable enabled, Windows automatically activates WinCLAT on eligible non-cellular interfaces when the following conditions are met.
WinCLAT is permitted. The Permit setting is enabled. Today, it is disabled by default in Windows.
The interface has an IPv6 address assigned using Stateless Address Autoconfiguration (SLAAC) and an IPv6 default route.
The interface has no native IPv4 connectivity. On an IPv6-mostly network, DHCPv4 option 108, called IPv6-Only Preferred (RFC 8925), tells a compatible client to operate without a native IPv4 address for the period specified by the DHCPv4 server. WinCLAT provides IPv4 application connectivity over IPv6 during that time.
A NAT64 prefix has been discovered, either from the PREF64 option in router advertisements (RFC 8781) or by querying ipv4only.arpa for AAAA records through a DNS64 server (RFC 7050). DNS64 is required for the DNS-based discovery method but is not required when WinCLAT discovers the prefix through PREF64.
NAT64 Gateway Requirements
Successful IPv4 connectivity through WinCLAT also requires a reachable NAT64 gateway configured to translate traffic using the discovered prefix. Discovering a prefix and activating WinCLAT do not confirm that the gateway is reachable or that traffic can pass through it.
Automatic and Manual Activation
AutoEnable is enabled by default and allows Windows to activate WinCLAT automatically when an interface meets the required conditions. Manually enabled instances behave differently, as described later in this post. WinCLAT can be enabled manually on a specific interface after automatic activation is disabled. When WinCLAT is translating, Windows assigns the interface an IPv4 address from the 192.0.0.0/29 IPv4 Service Continuity Prefix (RFC 7335) and adds an IPv4 default route through WinCLAT.
Installing the Module
The WinCLAT module is available in the PowerShell Gallery and runs on Windows PowerShell 5.1 and PowerShell 7. Run the following command to install the module.
Install-Module -Name WinCLAT -Scope CurrentUser
The module is needed only on the computer running the commands. Remote computers require WinRM, and commands that read interface state or change configuration require an elevated session on the target.
Step 1: Run Test-WinCLAT
Test-WinClat is the starting point for any WinCLAT problem. Run it from an elevated session so the interface checks can run.
Test-WinClat
The summary shows the overall result (Pass, Warning, Fail, or NotApplicable), whether any interface is translating, and the checks that returned a warning or failure. Individual checks can also return Info for conditions that do not affect the overall result. To display every check and its explanation, use -Detailed with Format-List.
The following is a list of checks that Test-WinClat performs.
Test
What it verifies
Feature present
The clat netsh.exe context exists on the computer
CLAT permitted
Permit is enabled in the active (effective) configuration
Prefix discovery valid
At least one of Pref64FromRA and Pref64FromDns is enabled
Policy override
Group Policy is not overriding the local configuration
SLAAC address
The interface has an IPv6 address from SLAAC
IPv6 default route
The interface has an IPv6 default route
Native IPv4
The interface has no native IPv4 address
Instance active
WinCLAT is translating when its prerequisites are met
CLAT address
The WinCLAT IPv6 address is assigned to the interface and on its current prefix
Prefix consistency
The NAT64 prefix matches the prefix returned by DNS64, when DNS64 is available
Mode sanity
WinCLAT can activate: AutoEnable is enabled, or an instance has been enabled manually
Functional test
IPv4 traffic passes through WinCLAT (optional)
Global checks do not require elevation. Interface checks are skipped, rather than failed, when the session is not elevated. Results of Info are informational and do not affect the overall result.
Step 2: Inspect the Configuration
Get-WinClatConfiguration returns the global settings. Use -Store Both to compare the active (effective) configuration with the persistent (local) configuration.
Get-WinClatConfiguration -Store Both
Compare the active configuration with the persistent configuration to identify differences between the effective settings and the locally stored settings. Use the PolicyControlled property to identify settings controlled by Group Policy. This property also identifies policy-controlled settings whose effective values match the local values, which a comparison of the two stores alone would not reveal.
Step 3: Inspect the Instances
Get-WinClatInstance returns the WinCLAT state of each IPv6-enabled interface. It requires elevation.
Get-WinClatInstance
Two properties are particularly useful when troubleshooting:
Mode shows whether the instance was enabled Automatically by Windows or Manually by an administrator.
TriggerSource shows why the instance was enabled: Pref64 RA (the network advertises PREF64), No IPv4 (the interface has no IPv4 connectivity), or Manual. It is read from event 1106 in the Microsoft-Windows-IPxlatCfg/Operational event log.
Common Problems
The following are common problems associated with WinCLAT configuration and operation.
Feature Not Present
Get-WinClatConfiguration returns Status FeatureNotAvailable, and Test-WinClatfails the Feature present check. WinCLAT is generally available on Windows 11 25H2 build 26200.9550 and later. The OSBuild property shows each computer’s build number, making it easy to identify computers that need the latest cumulative update.
WinCLAT is not available on Windows Server. Servers return StatusNotSupported, and Test-WinClat reports an overall result of NotApplicable.
WinCLAT Not Permitted
Permit is disabled by default, so WinCLAT does not activate automatically on Wi-Fi or Ethernet interfaces until Permit is enabled, either locally or through Group Policy. Test-WinClat fails the CLAT permitted check only when an interface is IPv6-only and could use WinCLAT. On a dual-stack network, the check is informational because WinCLAT would not be used there anyway.
With AutoEnable enabled, WinCLAT activates on eligible interfaces as soon as Permit is enabled.
DHCPv4 Option 108
Permit also affects DHCPv4 option 108. Windows honors option 108 only while WinCLAT is permitted. With Permit disabled, a client on an IPv6-mostly network accepts a DHCPv4 lease and uses native IPv4, so WinCLAT is not needed, and the CLAT permitted check is informational.
WinCLAT Not Active on Dual-Stack Network
This is expected. WinCLAT does not activate on an interface with native IPv4. Test-WinClatreports Native IPv4 and Instance active as Info on dual-stack interfaces. If a dual-stack interface has no SLAAC address or no IPv6 default route, as on a network that assigns IPv6 addresses with DHCPv6 only, those checks are also Info rather than Fail, because they matter only if the network becomes IPv6-only.
SLAAC Addressing Not Present
WinCLAT requires an IPv6 address configured using SLAAC. An interface whose IPv6 addresses are assigned only through DHCPv6 does not meet this requirement. DHCPv6 can still provide other configuration information, such as DNS server addresses and a domain search list. Test-WinClat checks for a SLAAC address and reports when an interface that needs WinCLAT does not have one.
Group Policy Overrides Local Configuration
Netsh.exe reports success when a local change is made to a setting that Group Policy controls, but the effective value does not change. Set-WinClatConfiguration reads the configuration back after every change and reports the result with StatusPolicyOverride when the policy keeps a different value.
In addition, Test-WinClat indicates when local settings conflict with Group Policy enforced settings.
Group Policy can control Permit, Pref64FromRA, and Pref64FromDns. There is no policy for AutoEnable. The policy values are stored in the following registry location.
An instance that is enabled but has no NAT64 prefix cannot translate. Test-WinClat fails the Instance active check and names the prefix discovery methods that are enabled. Common causes include:
The network does not include the PREF64 option in router advertisements, and Pref64FromDns is disabled.
No usable NAT64 prefix is available through router advertisements, and Pref64FromDns is enabled, but the DNS servers assigned to the client do not provide DNS64.
Both Pref64FromRA and Pref64FromDns are disabled. Netsh.exe accepts this combination silently, but WinCLAT can never activate. Set-WinClatConfiguration refuses it.
When WinCLAT discovers a NAT64 prefix through the PREF64 option in router advertisements, DNS64 is not required for prefix discovery or for translating IPv4 application traffic. A reachable NAT64 gateway using that prefix is still required. If DNS64 is unavailable, the Prefix consistency check is informational because there is no DNS64-derived prefix to compare.
Delayed WinCLAT Activation
WinCLAT activates fastest when the network advertises the NAT64 prefix through PREF64. When DNS64 is the only available prefix discovery method, Windows first waits to determine that the interface has no native IPv4 connectivity, so activation takes several seconds longer. Allow time for this process before treating an inactive instance as a configuration problem.
Manually Enabled Instances Continue Translating
Disabling Permit or AutoEnable stops translation on instances that Windows enabled automatically. Manually enabled instances can continue translating after either setting is disabled. When troubleshooting continued translation, check the instance’s Mode property to determine whether it was enabled manually.
Use Get-WinClatInstance to identify manually enabled instances.
Note that netsh.exe refuses to change an instance while AutoEnable is enabled. To return an interface from manual to automatic control, disable AutoEnable, disable the instance, and enable AutoEnable again:
Manual instance state is runtime only. It survives an adapter restart and link loss, but it is lost on reboot. Enabling an instance manually requires disabling AutoEnable, and AutoEnable remains disabled after the reboot, so WinCLAT does not activate at all. Enable AutoEnable again to restore automatic operation:
Set-WinClatConfiguration -AutoEnable Enabled
The Mode sanity check in Test-WinClat reports this condition.
IPv4 Fails After Moving to a Different Network
When a translating client moves to a different IPv6 network without restarting its network adapter, WinCLAT keeps its IPv6 address on the previous network’s prefix. The instance still reports that it is translating, but IPv4 traffic through WinCLAT fails. Microsoft has acknowledged this known issue and is working to resolve it in a future release.
Test-WinClat detects this condition. The CLAT address check fails, naming the address in use and the current prefix, while the Instance active check passes.
Restarting the network adapter resolves the issue.
Restart-NetAdapter -Name 'Ethernet'
The IPv6 address reported by netsh.exe interface clat show instance cannot be used to detect this condition, because it may report a new address that is not actually assigned to the interface. The CLAT address check compares the addresses actually assigned to the adapter with its current prefix.
Netsh.exe Reports Addresses That Are Not Assigned
An instance that is enabled but no longer translating can retain stale information in netsh.exe output. For example, a manually enabled instance on an interface that now has native IPv4 connectivity might still report a WinCLAT IPv6 address and 192.0.0.1 even though those addresses are no longer assigned to the interface. It might also display a NAT64 prefix with a remaining lifetime of zero. Use Get-NetIPAddress to confirm the addresses assigned to the interface. Clear the manual instance using the three-command sequence shown earlier or restart the computer.
Testing the Translation Path
The checks above assess WinCLAT configuration and local instance state. The functional test verifies connectivity to a specific IPv4 destination through WinCLAT and the NAT64 gateway. Use Test-WinClat with an IPv4 target address that is reachable through the gateway and known to respond to the selected test.
Keep the following in mind when interpreting the result.
Use an IPv4 address as the target. A hostname can resolve to a synthesized AAAA record through DNS64, allowing the connection to use IPv6 through NAT64 without using WinCLAT. Testing with an IPv4 address ensures the test uses IPv4. Check the selected interface and source address to confirm that the traffic passes through WinCLAT.
Native IPv4 can bypass WinCLAT. If another interface provides native IPv4 connectivity to the test destination, Windows might send the test traffic through that interface. The module reports Info when the selected path bypasses WinCLAT, even if the destination responds successfully. Review the Detail property to identify the selected interface and source address and confirm whether the test used WinCLAT.
Unreachable destinations time out. ICMP destination unreachable messages that NAT64 returns for IPv4 destinations are not delivered to the IPv4 application, so a test to an unreachable or filtered address returns a Warning after timing out rather than an immediate failure. Choose a target that is known to respond, ideally on your own infrastructure.
One test covers one path. When several interfaces translate, the test proves that IPv4 works through the interface Windows chose, not on each interface.
Troubleshooting at Scale
The WinCLAT commands accept computer names from the pipeline, including input from Get-Content and Get-ADComputer, and process remote computers in parallel over WinRM. Before connecting, the module checks TCP port 5985. If that connection fails, it reports the computer as Unreachable without waiting for a full WinRM timeout. This status indicates that the module could not reach the required endpoint. The computer might be offline, the port might be blocked, or WinRM might be configured to use a different TCP port.
Filtering and Exporting Results
The module returns a result for every target computer, including those that cannot be reached, do not support the feature, or cannot be fully checked because the session lacks elevation. The Status property identifies the outcome, and the Message property explains it.
# Test every computer in an OU and show only the computers with problems
The output is flat, so it exports cleanly with Export-Csv for reporting and comparison over time.
Known Issues
The following Windows behaviors can affect WinCLAT operation and troubleshooting. The module can identify some of these conditions, but it does not correct the underlying Windows behavior. Available workarounds are listed below.
Issue
Effect
Workaround
WinCLAT keeps its IPv6 address on the previous prefix after a network change
IPv4 traffic through WinCLAT fails; Test-WinClat reports CLAT address Fail
Restart the network adapter
WinCLAT IPv4 address is dynamically registered in DNS
Connections to the client may fail when DNS resolves its name to a WinCLAT IPv4 address
None
Translated ICMP errors are not delivered to IPv4 applications
Unreachable IPv4 destinations time out instead of failing immediately
None
Summary
Troubleshooting WinCLAT starts with Test-WinClat, which checks every prerequisite, explains each failure, and suggests remediation. Get-WinClatConfiguration reveals Group Policy overrides, and Get-WinClatInstance shows whether each instance was enabled automatically or manually. Most problems come down to a few causes: Permit disabled by default, Group Policy overriding local settings, no NAT64 prefix discovered, a manual instance that does not follow the global settings, or a stale WinCLAT address after a network change. Because netsh.exe reports success even when a change does not take effect, always verify the result by reading the state back, which the WinCLAT module does automatically.
Windows CLAT (WinCLAT) is now generally available, and many organizations are beginning to evaluate it in their IPv6-mostly and IPv6-only environments. I’ve written extensively about WinCLAT recently, including how it works, when to use it, and how it discovers the NAT64 prefix. Today, I’m pleased to announce the release of the WinCLAT PowerShell module, a free, open-source tool that makes managing, reporting on, and troubleshooting WinCLAT much easier, especially at scale.
Background
Today, WinCLAT is configured and managed using the netsh.exe.exe interface clat command context. While netsh.exe works well enough on a single computer, it has some notable limitations. Its output is plain text, which is difficult to filter, sort, or export. It also provides no built-in way to collect information from many computers at once. And, in some cases, netsh.exe reports success even when Group Policy overrides the change, which can be misleading.
The WinCLAT PowerShell module addresses these challenges. It wraps netsh.exe and returns structured objects to the pipeline, so administrators can work with WinCLAT the same way they work with any other PowerShell command. Every function runs against the local computer or against many remote computers in parallel using WinRM.
Key Features
Version 1.0 of the WinCLAT PowerShell module includes the following capabilities.
Fleet-wide reporting. Every function accepts computer names directly, from a text file using Get-Content, or from Get-ADComputer. Results include one row for every computer, including those that are offline, do not have the feature, or are not elevated. It detects unreachable computers in about two seconds rather than waiting for a WinRM timeout.
Health checks with remediation. Test-WinClat checks the global configuration and every IPv6-enabled interface, explains each warning and failure, and optionally validates the CLAT path end to end.
Safe configuration changes. Set-WinClatConfiguration refuses changes that would prevent CLAT from ever activating, reads back every change to detect Group Policy overrides, and prompts for confirmation before any change that stops CLAT.
Baselines. Export and import the WinCLAT configuration or reset computers to the Windows defaults.
Structured output. Every function returns flat objects that can be filtered, sorted, and exported to CSV.
Every result includes a Status property (Success, Unreachable, FeatureNotAvailable, NotSupported, ElevationRequired, PolicyOverride, or Failed) and a Message property that explains anything other than Success.
Requirements
The WinCLAT PowerShell module has the following requirements.
Windows PowerShell 5.1 or PowerShell 7 on the computer running the commands.
Windows 11 25H2 build 26200.9550 or later on target computers. WinCLAT is not available on Windows Server.
WinRM enabled on remote target computers.
Administrative privileges on target computers for Get-WinClatInstance, the Set, Import, and Reset functions, and the interface checks performed by Test-WinClat. Get-WinClatConfiguration and Export-WinClatConfiguration do not require elevation.
English (en-US) netsh.exe output on target computers.
Installation
The WinCLAT module is available in the PowerShell Gallery. To install it, open an elevated PowerShell window and run the following command.
Install-Module -Name WinCLAT
The module needs to be installed only on the computer where the commands are run. It is not required on target computers. To update to the latest release, run the following command.
Update-Module -Name WinCLAT
Once installed, run the following command to view the available functions.
Returns the WinCLAT configuration to the Windows defaults
Every function accepts the -ComputerName, -Credential, and -ThrottleLimit parameters. The -ComputerName parameter accepts pipeline input, including output from Get-Content and Get-ADComputer. Blank lines and lines beginning with # are ignored, so a simple text file of computer names works without modification. The default -ThrottleLimit is 32 concurrent connections.
Get-WinClatConfiguration
The Get-WinClatConfiguration function returns the global WinCLAT settings: Permit, Pref64FromDns, Pref64FromRA, and AutoEnable. By default, it returns the active (effective) configuration. Use the -Store parameter to view the persistent (local) configuration, or both. Comparing the two is helpful for identifying settings controlled by Group Policy. The output also includes the OS build number, which is useful for tracking which computers have received the feature.
Get-WinClatConfiguration -Store Both
Get-WinClatInstance
The Get-WinClatInstance function returns the WinCLAT state for each active network interface with IPv6 enabled. The output shows whether the interface is translating, the NAT64 prefix and its remaining lifetime, and the CLAT addresses assigned. It also reports whether the instance was enabled automatically or manually (Mode and TriggerSource), which the module reads from the Microsoft-Windows-IPxlatCfg/Operational event log.
Get-WinClatInstance
To identify every interface actively translating across a group of computers, run the following command.
Note: Get-WinClatInstance requires administrative privileges on the target computer.
Test-WinClat
Test-WinClat is the function I expect administrators will use most often. It performs a series of health checks on the global configuration and on each IPv6-enabled interface. By default, it returns a single summary per computer with an overall result of Pass, Warning, Fail, or NotApplicable, along with a list of the checks that failed or returned a warning.
Test-WinClat
Use the -Detailed switch to return one result per check. Each warning and failure includes a Detail explaining what was found and a Remediation describing how to correct it.
Test-WinClat -Detailed | Format-List
Note: The screen capture above contains additional information. It has been truncated for brevity.
Global checks include whether the feature is present, whether CLAT is permitted, whether NAT64 prefix discovery is enabled, and whether Group Policy overrides the local configuration. These do not require elevation. Interface checks include a SLAAC address, an IPv6 default route, the presence of native IPv4, an active CLAT instance, a CLAT address, and prefix consistency. Interface checks require administrative privileges and are skipped when the function is not run elevated.
Functional Test
Test-WinClat can also validate the CLAT path end to end. When the -IPv4Target parameter is specified, and an interface is translating, the function sends up to three ICMP echo requests to the target. Optionally, include the -IPv4Port parameter to test with a TCP connection instead. The results show which interface and source address the traffic used.
Important: Always specify an IPv4 address, not a hostname, for -IPv4Target. A hostname can be reached using DNS64 and NAT64 without CLAT, which defeats the purpose of the test. Also, Windows prefers a native IPv4 route over CLAT. If the computer has native IPv4 connectivity on another interface, the functional test reports Info rather than testing CLAT.
To test many computers and return only failures and warnings, run the following command.
The Set-WinClatConfiguration function changes the global WinCLAT settings. Only the settings specified are changed. Before making any change, the function reads the current configuration and refuses any change that would leave both Pref64FromRA and Pref64FromDns disabled, since CLAT would never activate in that state. To enable WinCLAT, run the following command.
Set-WinClatConfiguration -Permit Enabled
Note: In the example above, the WinCLAT configuration is managed by group policy, which overrides the locally configured settings.
As I mentioned earlier, netsh.exe reports success even when Group Policy overrides a setting. To address this, Set-WinClatConfiguration reads back every change after it is made. If policy enforces a different value, the result is reported with a Status of PolicyOverride, as shown here.
The function supports -WhatIf. Disabling Permit or AutoEnable prompts for confirmation by default, because doing so stops CLAT on every interface where it was enabled automatically.
Set-WinClatInstance
The Set-WinClatInstance function manually enables or disables WinCLAT on a single interface, specified by name or interface index. This is primarily useful for testing and troubleshooting. Because netsh.exe refuses manual changes while AutoEnable is enabled, the function disables AutoEnable first, under a single confirmation prompt.
Please note that a Manual instance state does not survive a reboot, but the AutoEnable setting remains disabled. After a reboot, WinCLAT will not activate until AutoEnable is enabled again using Set-WinClatConfiguration -AutoEnable Enabled.
Reset-WinClatConfiguration
The Reset-WinClatConfiguration function returns the WinCLAT global configuration to the Windows defaults without requiring an export file. It sets Pref64FromDns, Pref64FromRA, and AutoEnable to enabled. Only settings that differ from the defaults are changed. To reset the WinCLAT configuration, run the following command.
Reset-WinClatConfiguration
Crucially, the Permit setting is changed only when the -Permit parameter is specified. This means a basic reset never stops CLAT. For a full reset to the current Windows defaults, including Permit, specify -Permit Disabled. Since this stops CLAT, the function prompts for confirmation by default.
Reset-WinClatConfiguration -Permit Disabled
Export and Import
The Export-WinClatConfiguration function saves the WinCLAT global configuration of one or more computers to the local computer, one file per computer. Files are named WinCLAT-<ComputerName>-<yyyyMMdd-HHmmss>.txt and are never overwritten, so repeated runs maintain a history of baselines. Export the WinCLAT configuration by running the following command.
Export-WinClatConfiguration -Path <folder name>
The Import-WinClatConfiguration function applies those files. Importantly, the files are never executed. Each file is parsed strictly, and any file containing content other than what netsh.exe writes is rejected before any computer is contacted. Only settings that differ from the file are changed.
Known Issues
During testing, I encountered the following issues. These are Windows behaviors, not issues with the module. They were observed on builds 26200.9711 and 26300.9711.
Stale CLAT address. After a network change, CLAT may retain its IPv6 address on the previous network’s prefix, causing IPv4 traffic through CLAT to fail. Test-WinClat reports a CLAT address failure in this scenario. Restarting the network adapter resolves the issue.
DNS registration. CLAT registers its IPv4 address (192.0.0.x) in DNS, which is unnecessary and may have negative side effects.
ICMP errors. ICMP error messages returned by NAT64 for IPv4 destinations do not reach IPv4 applications. As a result, ping to an unreachable IPv4 address times out rather than reporting that the destination is unreachable.
Summary
The WinCLAT PowerShell module makes it easier for administrators to configure, report on, and troubleshoot Windows CLAT across their environment. Whether you’re evaluating WinCLAT on a handful of test machines or preparing for a broad IPv6-only deployment, the module provides structured output, fleet-wide reporting, and built-in health checks that netsh.exe alone does not. Download it today from the PowerShell Gallery and let me know what you think. Feedback, issues, and feature requests are always welcome on GitHub.
On October 19, 2026, Microsoft announced an update for the Entra Global Secure Access (GSA) client. This latest release, v2.34.222, adds support for a new sign-in option, updates Conditional Access sign-in frequency, improves diagnostics, and enhances local network bypass. It also improves Windows Firewall behavior off network, along with telemetry and accessibility improvements.
The GSA client now supports Web sign-in for Windows. This credential provider enables browser-based Windows sign-in using methods such as Microsoft Authenticator, Temporary Access Pass (TAP), or a SAML-P federated identity. Web sign-in requires a Microsoft Entra-joined device running Windows 11 version 22H2 with KB5030310 or later, plus internet connectivity.
Windows Firewall Profile
This release improves Windows Firewall profile selection when Private Access is enabled. When the device is not directly connected to the corporate network, Windows Firewall does not activate the Domain profile.
Traffic Forwarding Profile Details
The new GSA client features improved diagnostics. With this update, the Forwarding profile tab in the Advanced diagnostics section now displays the Traffic Forwarding Profile Name as it appears in the Entra admin center, along with the Traffic Forwarding Profile ID.
Traffic Forwarding Profile Name and ID
Conditional Access
GSA client v2.34.222 now includes support for Conditional Access sign-in frequency for Private Access applications. This feature is part of a phased rollout and might not be available in all tenants immediately.
Prefer Local Network Bypass
With this update, the Prefer local network option limits bypass to connections destined for IP addresses in common private network ranges. Microsoft documentation doesn’t elaborate on specifically which ‘common private network ranges’, but I suspect this means private IPv4 address ranges as defined in RFC 1918.
GSA Traceroute Changes
In GSA client v2.34.222, Microsoft has replaced the command-line version of the GSA traceroute tool (GsaTracert.exe) with a new GUI version. However, during my initial testing (and confirmed by others testing this feature), it appears to be broken at this time. When I launch GsaTracert.exe, the UI returns the following error message.
“Could not retrieve the forwarding profile from the registry. Ensure the Global Secure Access Client is installed and running.”
I will post an update as soon as Microsoft resolves this issue.
Additional Changes
In addition to the changes highlighted above, the new GSA client includes the following additional enhancements.
UDP tunneling improvements
Memory utilization improvements
New telemetry capabilities
Accessibility improvements
Bug fixes and other miscellaneous improvements
Summary
GSA client v2.34.222 introduces several useful enhancements for administrators and users. Organizations should validate the update against their existing configuration before broad deployment. My initial testing also identified an issue with the updated diagnostic tool, as described above.
