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

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

<Sysmon schemaversion="4.82">
  <DnsLookup>False</DnsLookup>
  <EventFiltering>
    <NetworkConnect onmatch="include">
      <SourceIp condition="is any">192.0.0.1;192.0.0.2;192.0.0.3;192.0.0.4;192.0.0.5;192.0.0.6;192.0.0.7</SourceIp>
    </NetworkConnect>
    <NetworkConnect onmatch="exclude">
      <DestinationIp condition="begin with">224.</DestinationIp>
      <DestinationIp condition="begin with">239.</DestinationIp>
      <DestinationIp condition="is">255.255.255.255</DestinationIp>
      <DestinationIp condition="is any">192.0.0.0;192.0.0.1;192.0.0.2;192.0.0.3;192.0.0.4;192.0.0.5;192.0.0.6;192.0.0.7</DestinationIp>
    </NetworkConnect>
    <ProcessCreate onmatch="include" />
    <FileCreateTime onmatch="include" />
    <ProcessTerminate onmatch="include" />
    <DriverLoad onmatch="include" />
    <RawAccessRead onmatch="include" />
  </EventFiltering>
</Sysmon>

The configuration does the following.

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

Installing and Configuring Sysmon

Sysmon is available natively in Windows 11 since February, 2026, but it is not installed by default. Administrators can install it by navigating to Settings > System > Optional features > More Windows features and selecting Sysmon.

Optionally, administrators can install Sysmon by opening an elevated PowerShell command window and running the following command.

Enable-WindowsOptionalFeature -Online -FeatureName Sysmon

For Windows versions that don’t include Sysmon, administrators can download Sysmon from the Sysinternals website.

Applying the WinCLAT Filter

After installing Sysmon, open an elevated command window and install it with the configuration file by running the following command.

sysmon.exe -i sysmon-winclat.xml

To apply a changed configuration to a computer where Sysmon is already installed, use -c.

sysmon.exe -c sysmon-winclat.xml

Reading Sysmon Events

Events are recorded in the Microsoft-Windows-Sysmon/Operational log.

Sysmon event log indicating the calling application.

Sysmon event log indicating the source and destination IPv4 addresses used by the calling application.

Viewing Recent Events with PowerShell

Run the following command to display the time and message for up to 20 of the most recent Sysmon Event ID 3 records.

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Sysmon/Operational'; Id = 3 } -MaxEvents 20 | Format-List -Property TimeCreated, Message

Sysmon event log details viewed using PowerShell.

The example above shows several fields of interest for a TCP connection to an IPv4 address through WinCLAT.

Network connection detected:
ProcessId: 10536
Image: C:\Tools\putty.exe
User: LAB\rhicks
Protocol: tcp
Initiated: true
SourceIsIpv6: false
SourceIp: 192.0.0.1
SourcePort: 50935
DestinationIsIpv6: false
DestinationIp: 172.16.0.254
DestinationPort: 22

Listing Applications and User Accounts

To produce a list of the applications and destinations recorded on a computer, read the values from the event data and remove the duplicates.

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Sysmon/Operational'; Id = 3 } |
    Select-Object -Property @{ Name = 'Image'; Expression = { $_.Properties[4].Value } },
        @{ Name = 'User'; Expression = { $_.Properties[5].Value } } |
    Sort-Object -Property Image, User -Unique |
    Format-Table -AutoSize

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.

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.

Additional Information

Sysmon XML Configuration File for WinCLAT Tracing on GitHub

WinCLAT resources on directaccess.richardhicks.com