I've configured my DC (Domain Controller; Windows 2016) as described here to get his time from my Sophos-UTM. So i configured the GPO as described there. But after that and a restart of the server i noticed that when i run the command w32tm /query /status that under Source is Local CMOS Clock listed, but here should the IP from my Sophos-UTM be listed or am i wrong? In the Screenshots of my link above, when the author of it runs the same command, there is the correct ip from his configuration listed. So what's going wrong here?

All Ports which are needed (UDP 123) are openend and reachable. I've tested it and looked into my Firewall-Configurations. For testing purposes i run this command on the DC: w32tm /stripchart /computer:IP-OF-SOPHOS-UTM /dataonly /samples:5

With that command i get 5 Timestamp-Samples back from the Sophos-UTM, so my Firewall-Rules are working and the cinfiguration there is correct. I saw this in the logs, too.

This DC is a virtual machine, running in vSphere ESXi (free Version 7.0.1). Time Synchronisation between ESXi-Host and Guest is disabled as described in official vmWare Documentation.

Here are the Output of the command w32tm /query /status

Jump indicator: 0 (no warning)
stratum: 1 (primary reference - synchron. via radio clock)
Precision: -6 (15.625ms per tick)
stem delay: 0.0000000s
stem deviation: 10.0000000s
Reference ID: 0x4C4F434C (source name: "LOCL")
Last successful synchronization time: 07.12.2020 15:04:23
Source: Local CMOS Clock
Polling interval: 6 (64s)

Output of the command w32tm /query /configuration


EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)

FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)

NtpClient (Lokal)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Richtlinie)
ResolvePeerBackoffMaxTimes: 7 (Richtlinie)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 0 (Richtlinie)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 900 (Richtlinie)
Type: NTP (Richtlinie)
NtpServer: MY-SOPHOS-UTM-IP,0x5 (Richtlinie)

NtpServer (Lokal)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)

VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)

Output of the command w32tm /query /peers

Number Peers: 1

Status: Active
Time remaining: 495.5965885s
Mode: 1 (Symmetrically active)
Stratum: 0 (not specified)
Peer Retrieval Interval: 0 (not specified)
Host polling interval: 4 (16s)

Output of command w32tm /resync /rediscover

Resynchronize command is sent to the local computer.
The computer was not synchronized because no time data was available.

Very strange behaviour. Anybody out there, who has a solution for this?

  • Looks like you didn't set any peers to resolve against. Was that intentional? – Spencer Dec 7 '20 at 23:29
  • Waht do you mean with no peer is set? A peer ist set. When i run the command w32tm /query /peers i see the IP of my UTM set as peer, which is correct, but when i run w32tm /query /status is the source not the UTM but the Local CMOS Clock – Opa114 Dec 8 '20 at 8:55

Found the Solution for the problem, after a lot of hours of research.. In my case it was the Hewlett Packard Switch HPE OfficeConnect 1820

A feature on more recent HP Procurve models (18xx series, such as 1810G etc.) is called "Auto DoS". You can find it in the section "Security" and then "Advanced security".

If you enable the Auto DoS feature, traffic is blocked based on one of these conditions:

the source port (TCP / UDP) is identical to the destination port (NTP, SYSLOG, etc)

the source port (TCP / UDP) is 'privileged' thus in the range of 1 -1023.

This will cause all kinds of problems, but first this: "Why on earth is a Layer 2 device filtering on Layer 3?". This is just insane.

NTP does not work any more. Syslog traffic will not arive. VPN traffic may not arrive.

This issue cost me a lot of time to solve. I first blamed our Firewall, but the actual traffic arrived on the tagged trunk port on the affected switch. The traffic somehow was not sent to the switch port on which the destination device was connected.

Affected products:

HP ProCurve 1810G - J9449A ( 8 ports ) and J9450A ( 24 ports )

So after disabling the Auto DoS Protection function it works as expected. As Source in Windows is now the correct IP listed and not the Local CMOS Clock and now i see the traffic in tcpdump. So this could maybe the solution for other people, if they use a HP Switch.

After more research it seems that only the option Prevent UDP Blat Attack must be disabled. As mentioned here, Prevent UDP Blat Attack – UDP Source and Destination Port match. So after looking into tcpdump i saw that my UTM and the Windows Server both using port 123, so no wonder, why this option blocks the traffic....

Here a Screenshot of the final configuration. enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.