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.
I’m excited to announce that I’ll be presenting at the upcoming Workplace Ninjas US Conference, January 11–13, 2027, at The Scott Resort & Spa in Scottsdale, Arizona. The conference focuses on endpoint management, identity, security, and the modern workplace. The inaugural event in Dallas in December 2025 was exceptional, and the 2027 conference expands to three days of technical sessions and opportunities to connect with industry experts and fellow IT professionals.
Sessions
I’ll be presenting the following two sessions at the conference.
Moving to Zero Trust: Entra Private Access for Always On VPN Administrators – In this session, I’ll provide practical guidance for transitioning from traditional VPN access to Zero Trust Network Access (ZTNA) using Microsoft Entra Private Access.
Getting Started with Cloud PKI for Microsoft Intune – This session introduces Microsoft Cloud PKI for Intune, including common use cases and security best practices.
Who It’s For
This conference is well-suited to IT professionals who manage and secure Microsoft environments, including administrators, engineers, architects, consultants, and security leaders. Topics include:
Microsoft Intune and Configuration Manager
Microsoft Entra and identity management
Microsoft Defender and Zero Trust security
Desktop as a Service (DaaS) and virtual desktop infrastructure (VDI)
Automation
Registration
Registration is now open, and conference admission is just $650 for all three days. Hotel packages are also available. Visit the registration page for details and to reserve your place. I hope to see you in Scottsdale!
Heads up, fellow Windows Server administrators! There are now just THREE MONTHS remaining before Windows Server 2016 reaches end of support, so now is the time to finalize any migrations for workloads hosted on this platform. Mainstream support ended on January 11, 2022, and Windows Server 2016 has since remained in extended support. However, extended support ends on January 12, 2027. After that date, Microsoft will no longer provide security updates or technical support, increasing the risk of running production workloads due to exposure to newly discovered vulnerabilities and exploits.
Active Directory Certificate Services
Many organizations are still running critical infrastructure on Windows Server 2016. Administrators often delay upgrading Microsoft Active Directory Certificate Services (AD CS) due to its complexity. However, a well-planned AD CS migration not only reduces risk but also provides an opportunity to modernize cryptography, certificate templates, and operational practices.
Certificate Authorities
Administrators must carefully migrate Certificate Authorities (CAs) running on Windows Server 2016 to minimize downtime. In environments where ongoing CA maintenance has been limited, migrating the CA database can be especially challenging. If the CA is installed on a domain controller, now is a good time to consider separating these services to ensure reliable operation. Also, it’s a good idea to evaluate the CA’s configuration and security posture during migration to enhance security and improve service resilience.
NDES Servers
Microsoft Network Device Enrollment Services (NDES) servers, commonly deployed to facilitate certificate enrollment via Microsoft Intune, pose a unique challenge during migration. Unfortunately, configuring NDES is exceedingly complex and error-prone. NDES relies on a delicate combination of specialized IIS configuration, AD service accounts, custom certificate templates, and CA permissions, making even minor changes risky without proper planning. Not surprisingly, administrators are often hesitant to touch these systems as they are notoriously difficult to troubleshoot when problems arise.
Don’t overlook Windows Server 2016 servers with the Intune Certificate Connector installed. Fortunately, this is one of the more manageable workloads to migrate. All that’s required is to install new connectors on supported servers and delete the old ones.
Summary
With extended support for Windows Server 2016 ending on January 12, 2027, organizations running production workloads—especially critical infrastructure such as Active Directory Certificate Services (AD CS), Certificate Authorities (CAs), and NDES servers—face significant security risks from unpatched vulnerabilities once the OS reaches end-of-life. Careful migration planning to newer versions such as Windows Server 2022 or 2025 is essential to minimize downtime, improve security posture, and ensure long-term resilience.
Start Planning Now
Don’t risk running unsupported workloads in 2027! Complete your migration today. If you’d like expert guidance, I have many years of experience migrating these workloads. I have developed specialized tools and techniques to ensure a smooth, secure, and successful transition. Fill out the form below to schedule a free one-hour consultation to assess your Windows Server 2016 AD CS workloads, identify migration risks, and outline next steps.
When deploying on-premises enterprise PKI certificates using Microsoft Intune with Simple Certificate Enrollment Protocol (SCEP) certificate profiles, administrators must deploy a Windows Server with the Network Device Enrollment Service (NDES) role installed. Once configured, the Microsoft Intune Certificate Connector can be installed and configured to allow administrators to issue and manage certificates for their Intune-managed endpoints.
Configuration Failed
After configuring NDES, administrators may encounter an error message when installing the Microsoft Intune Certificate Connector. The message states:
Configuration Failed
Configuring Microsoft Intune Certificate Connector failed. No changes were made to Feature or Proxy settings. Please try again.
Unexpected Failure. Error: System.ArgumentException: String cannot be of zero length. Parameter name: name at System.Security. PrincipaI.NTAccount..ctor(String name) at Microsoft.lntune.Connectors.ConfigUlScep.SetServiceUserPermissions(String username) at Microsoft.lntune.Connectors.ConfigUlScep.SetNdesUserPermissions(String username) at Microsoft.lntune.Connectors.ConfigUlScep.Enable() at Microsoft.Intune.Connectors.ConfigUI.ApplyConfiguration.<ApplyChanges>d__10.MoveNext()
Missing Service Account
This error occurs because the administrator configured the NDES role using the default application pool identity, which the Intune Certificate connector does not support.
Resolution
To resolve this issue, configure the SCEP application pool to run as a Group Managed Service Account (gMSA), which is a security best practice. Alternatively, you can configure the SCEP application pool to run as a regular domain service account (not recommended).
SCEP Application Pool Configuration
To update the SCEP application pool to run as a gMSA or domain service account, add the service account to the IIS_IUSRS group. If running as a domain service account and not a gMSA, be sure to also grant the service account the Logon as a Service right.
Next, open Internet Information Services (IIS) Manager (inetmgr.exe) and follow the steps below.
Expand the NDES server in the navigation tree.
Highlight Application Pools.
Right-click the SCEP application pool and choose Advanced Settings.
In the Process Model section, highlight Identity.
Click the ellipses next to ApplicationPoolIdentity.
Select Custom account.
Click Set.
Enter the service account using the domain\username format. Be sure to include the trailing $ when specifying a gMSA.
If using a standard domain service account, enter and confirm the password.
Click Ok three times.
Finally, stop and start the application pool for the changes to take effect.
Note: Using a gMSA requires additional configuration in the domain. Detailshere.
Once complete, be sure to assign the Request Certificates permission to the gMSA or domain service account on the issuing certification authority (CA) server. In addition, assign Enroll permission to the service account on the NDES certificate template in Active Directory (AD).
Intune Certificate Connector
The Intune Certificate Connector does not support running under a gMSA. However, when using NDES/SCEP, it’s acceptable to run the connector service under the SYSTEM account. Ensure the connector server’s computer account is granted Issue and Manage Certificates permissions on the issuing CA server.
Summary
For NDES used with Intune SCEP certificate profiles, a group Managed Service Account (gMSA) is the preferred service account. A standard domain user account is supported if a gMSA is not an option. Specify the account when you configure the NDES role or leave the default ApplicationPoolIdentity and replace it with the gMSA before installing the Intune Certificate Connector.
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.
Microsoft recently introduced custom Entra Private Accesstraffic forwarding profiles in public preview. Administrators can now provide different sets of private applications to selected users, groups, devices, and device platforms. This post explains how the profiles are assigned and prioritized, how to configure one, and how the new local network option handles overlapping address space.
Forwarding Profiles v1
Previously, organizations could assign the default Private Access traffic forwarding profile to selected users and groups, but they could not create separate Private Access profiles with different acquisition rules for different target groups. That made it difficult to give Windows devices one set of private application destinations and mobile devices another. Administrators could still control access through application assignments and Conditional Access, but the traffic the client acquired was less tailored to the user or device.
Forwarding Profiles v2
Global Secure Access (GSA) provides default traffic forwarding profiles for Microsoft traffic, Private Access, and Internet Access. Administrators can also create custom Private Access profiles and scope them to users, groups, devices, and device platforms. During the preview, a tenant can have up to 10 custom Private Access profiles.
Policy Processing
GSA evaluates traffic against the Microsoft, Private Access, and Internet Access profile types in that order. Traffic that matches none of them is not forwarded to the service. This order is separate from the priority used to choose between multiple applicable Private Access profiles.
Multiple Profiles
Each custom Private Access profile has its own acquisition rules, assignments, status, and priority. Assign a priority from 101 through 199. A lower number represents a higher priority. When more than one enabled Private Access profile applies to the same user and device, the client uses only the highest-priority applicable profile. The application rules from the other profiles are not combined with it.
Configure a Custom Private Access Profile
In the Microsoft Entra admin center, go to Global Secure Access > Connect > Traffic forwarding. Select Create new traffic forwarding profile, then Private access profile. Enter a descriptive name and, optionally, a description. Set a priority from 101 through 199 and choose whether the profile is enabled. Select Next, review the settings, and select Create. Note that the new profile has no acquisition rules or assignments until you configure them.
Acquisition Rules
Open the new profile and select Acquisition rules. Choose whether to include Quick Access destinations, then select the Private Access applications whose destinations the profile should acquire. Adding an application to a forwarding profile determines which traffic the client captures. Users must also be authorized to connect to the application’s resources.
Including Quick Access Destinations
Including Quick Access adds its configured destinations to the acquisition rules of this profile alongside the selected Private Access applications. This can provide a common set of destinations across custom profiles, but it does not change the Quick Access application’s configuration or grant users access to its resources. Confirm that the intended users are assigned to Quick Access as well as to the forwarding profile.
Assignments
Under Assignments, select View next to User and device assignments. Choose All users and devices or Selected users and devices, then save your selection.
Next, select View next to Device platform assignments and choose the supported platforms that should receive the profile. A device must match both assignment conditions. For example, selecting a user group and Windows limits the profile to Windows devices used by members of that group.
The new profile appears in the traffic forwarding list by priority, as shown here.
On an assigned client, open Advanced diagnostics > Forwarding profile to confirm that the expected Private Access application segments are present, as shown here.
Prefer Local Network
The Windows GSA client includes a Prefer local network option for cases where a local subnet overlaps with a configured private application destination. When an administrator enables the option, it appears in the client settings. A user can select it to keep applicable local subnet traffic on the local network, such as traffic to a printer or screen casting device, instead of having the client acquire that destination for Private Access. Microsoft introduced the option in Windows GSA client version 2.32.294.
The Problem It Solves
Overlapping private address space can make a local destination look like a destination defined in a Private Access application segment. For example, a user’s home printer and a corporate resource might both use 192.168.1.50. Prefer local network lets the user favor the directly connected local destination in this situation, such as when printing or screen casting.
Intelligent Local Access
Intelligent Local Access (ILA) serves a different purpose. It uses configured DNS probes to identify a corporate private network and can then send traffic directly to specified Private Access applications available on that network. Prefer local network addresses when there is an overlap between the device’s local subnet and a Private Access destination, such as a printer on a home network. ILA depends on a matching configured private network and application. An address overlap alone does not trigger it.
Summary
Custom Private Access traffic forwarding profiles give administrators more control over which private application destinations the Global Secure Access (GSA) client acquires for different users and devices. Assignments determine who receives a profile, while priority determines which profile applies when assignments overlap. The Prefer local network option also helps Windows users reach local devices when their subnet overlaps a Private Access destination.
