WSL mirrored networking + ntpsec can interfere with Windows Time (w32time) sync

[asweet-confluent]

Windows Version

Microsoft Windows [Version 10.0.22631.6199]

WSL Version

2.5.10.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2 (custom build)

Distro Version

Ubuntu 25.04

Other Software

• NTP daemon inside WSL (ntpsec/plucky,now 1.2.3+dfsg1-3)
• Windows Time service: w32time (built-in)

Repro Steps

1. Enable WSL2 mirrored networking in %UserProfile%\.wslconfig:

   [wsl2]
   networkingMode=mirrored

   Then restart WSL:

   wsl --shutdown

2. Stop Windows Time service:

   net stop w32time

3. In the WSL Ubuntu distro, enable and start ntpsec:

   sudo systemctl enable --now ntpsec.service

4. Start Windows Time service and attempt a resync:

   net start w32time
   w32tm /resync /force
   w32tm /query /status

5. Workaround: disable ntpsec inside WSL and retry Windows sync:

   sudo systemctl disable --now ntpsec.service

   Then on Windows:

   w32tm /resync /force
   w32tm /query /status

---

Expected Behavior

I’d expect the Windows host time sync (w32time) to keep functioning normally. If this host/guest combination (especially with mirrored networking) isn’t intended to work, a note in docs would help since the symptom presents as a host failure with no obvious WSL linkage.

Actual Behavior

With mirrored networking enabled and ntpsec.service running in WSL, Windows Time service fails to sync and the host clock drifts:

C:\Windows\System32>w32tm /resync /force
Sending resync command to local computer
The computer did not resync because no time data was available.

I'm assuming it's just ntpsec conflicting with this:

The built-in W32Time NTP client can only use UDP 123 as the source port.

There appears to be a race condition between Windows Time service and ntpsec, and whichever one binds first will cause the other to fail. On my system, ntpsec has been consistently winning for at least a few months.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.

Thank you!