Understanding Windows CLAT (WinCLAT) Event Logging

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.

Contents

Locating WinCLAT Event Logs

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.

Get-WinEvent -LogName 'Microsoft-Windows-IPxlatCfg/Operational' -MaxEvents 10 | Format-Table -Property TimeCreated, Id, Message -Wrap

Recent WinCLAT events displayed using PowerShell.

Creating a WinCLAT Custom View

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.

  1. Right-click Custom Views and choose Import Custom View.
  2. Select the winclat-event.xml file downloaded previously and click Open.
  3. Review the Name and Description of the Custom View and click OK.
  4. Click OK.

WinCLAT events displayed in an Event Viewer custom view.

WinCLAT Event ID Reference

The following table shows the WinCLAT event IDs.

Event IDDescriptionWhen it is recorded
1106Instance enabledCLAT is enabled on an interface, automatically or manually
1107Instance disabledCLAT is disabled on an interface
1108Remote prefix discoveredCLAT discovers the NAT64 prefix for an interface
1109Translation startedCLAT begins translating on an interface
1110Translation stoppedCLAT stops translating on an interface
1111CLAT IPv6 address DAD failureThe 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.

CodeTrigger sourceMeaning
1Pref64 RAEnabled automatically because the network’s router advertisements include the PREF64 option
3No IPv4Enabled automatically because the interface has no IPv4 connectivity
5ManualEnabled 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.

$Adapters = @{}
Get-NetAdapter | ForEach-Object -Process { $Adapters[[uint64]$_.NetLuid] = $_.Name }
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-IPxlatCfg/Operational'; Id = 1106 } |
    Select-Object -Property TimeCreated,
        @{ Name = 'TriggerSource'; Expression = { Switch ($_.Properties[0].Value) { 1 { 'Pref64 RA' } 3 { 'No IPv4' } 5 { 'Manual' } Default { "Unknown ($_)" } } } },
        @{ 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.

Additional Information

Windows CLAT (WinCLAT) PowerShell Module on GitHub.com

Troubleshooting Windows CLAT (WinCLAT) with the WinCLAT PowerShell Module

Windows CLAT (WinCLAT) Frequently Asked Questions (FAQ)

WinCLAT resources at directaccess.richardhicks.com

Absolute Secure Access and IPv6

Absolute Secure Access (formerly NetMotion Mobility) is a premium enterprise secure remote access solution with deep user and application insight supporting Windows, Mac, iOS (iPhone and iPad), and Android devices. Although Absolute Secure Access supports IPv6 for remote network connections and client IP address assignment, the latter is not enabled by default. Administrators must make additional changes to the configuration to assign IPv6 addresses to their clients so they can access resources inside the tunnel using IPv6.

DHCPv6 and SLAAC

Absolute Secure Access supports DHCPv6 and Stateless Address Autoconfiguration (SLAAC) methods for assigning IPv6 addresses to connected clients. Although IPv6 client addressing is not enabled by default, it is quick and easy to configure.

Note: Absolute Secure Access does not currently support static IPv6 prefix assignment.

Enable IPv6

To enable IPv6 global support for all Absolute Secure Access clients, open the Secure Access management console and navigate to Configure > Client Settings > Virtual Address > Allocation Method: IPv6. Administrators can choose to support either DHCPv6 alone or DHCPv6 and SLAAC. After making a selection, click the Apply button to save the changes.

Once configured, Absolute Secure Access clients will be assigned an IPv6 address and can access IPv6 resources over the Secure Access tunnel.

Split Tunneling

If you have configured the Absolute Secure Access policy for split tunneling, ensure you have included your internal IPv6 prefix(es) defined in the split tunneling policy.

Additional Information

NetMotion Mobility is now Absolute Secure Access

Absolute Secure Access Zero Trust Network Access (ZTNA)

What’s New in Absolute Secure Access v13

Absolute Secure Access Features and Capabilities

Absolute Secure Access Advanced Features In Depth

Enterprise Zero Trust Network Access (ZTNA) and VPN

Always On VPN and IPv6

Internet Protocol version 6 (IPv6) has been with us for nearly 30 years. IPv6 adoption on the public Internet has steadily increased over the last decade, and today is approaching 50%. However, enterprise adoption of IPv6 has been surprisingly sluggish despite its numerous benefits. IPv6 includes an expanded address space that removes complex subnetting requirements and globally unique addressing that eliminates the need to perform Network Address Translation (NAT), among others. Organizations should consider deploying IPv6 internally to take advantage of these capabilities.

IPv6 and RRAS

I’ve deployed Microsoft Always On VPN for customers using IPv6 numerous times. The following describes configuration settings required to support IPv6 in a Microsoft environment using a Windows Server Routing and Remote Access (RRAS) server.

To begin, open the Routing and Remote Access management console (rrasmgmt.msc) on the RRAS VPN server, then follow the steps below to enable IPv6 support for Always On VPN connections.

Note: The configuration below assumes that IPv6 is already deployed on the internal network, either natively or dual-stacked with IPv4.

IPv6 Remote Access

Perform the following steps to enable IPv6 remote access on the RRAS VPN server.

  1. Right-click the RRAS VPN server in the navigation tree and choose Properties.
  2. Check the box next to the IPv6 Remote access server on the General tab.

Prefix Assignment

Next, an IPv6 prefix must be assigned to each RRAS VPN server. This IPv6 prefix must be unique for each server and not in use anywhere else on the internal network. Unlike IPv4, IPv6 addresses cannot be assigned from the same prefix (subnet) as the VPN server’s internal network interface. With that, ensure that internal network IPv6 routing returns traffic for the assigned IPv6 prefixes to the corresponding VPN server.

Perform the following steps to assign an IPv6 prefix for VPN client use.

  1. Right-click the RRAS VPN server in the navigation tree and choose Properties.
  2. Select the IPv6 tab.
  3. Check the box next to Enable IPv6 Forwarding.
  4. If force tunneling is required (not recommended), check the box next to Enable Default Route Advertisement.
  5. Enter an IPv6 prefix in the IPv6 prefix assignment field. Again, ensure the IPv6 prefix is globally unique, and that internal network routing is configured to return traffic to the VPN server that owns the prefix.
  6. If your RRAS server is multi-homed, select the internal network interface from the Adapter drop-down list.

DHCP

Organizations with IPv6 deployed internally may use Microsoft Windows DHCPv6 or a dedicated DNS/DHCP/IP Address Management (IPAM) (DDI) solution like Infoblox. However, Windows Server RRAS does not support DHCPv6 for VPN client IP address assignment. Administrators must manually assign an IPv6 prefix per server. However, administrators can use DHCP alongside IPv6 prefix assignment for VPN client IPv4 addressing.

Limitations

While IPv6 may solve some problems for Always On VPN administrators, it has some limitations. Here are some crucial considerations for IPv6 and Always On VPN at the time of this writing.

Traffic Filters

You cannot use IPv6 when configuring traffic filters for Always On VPN. Specifying IPv6 elements in a traffic filter rule will prevent Always On VPN from working at all. More details here.

Intune and Routing

When split tunneling is enabled, Microsoft Intune will not accept IPv6 routes using the standard IPv6 subnet prefix of /64. The UI complains that “the value must be between 1 and 32”.

You can use the custom XML deployment option to configure Always On VPN to support split tunneling correctly as a workaround.

Additional Information

Overview of IPv6

Everything You Never Knew about NAT

Disabling IPv6 Breaks Windows Server RRAS

Microsoft Always On VPN Traffic Filters and IPv6

Discussing Microsoft and IPv6 on the IPv6 Buzz Podcast (Packet Pushers)