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.
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.
