Log Entries with Date in the Future

[IsaacFL]

I have seen instances where the time on the logs is not the time on the system.

Maybe it is due to Hyper-V? I am using Hyper-V 2019 Core.

I have attached a picture, see the Firewall Logs, then look at the current time, and you see the Logs have a date that is in the future. When I first noticed it, it was about 10 minutes ahead.

I upgraded today to the 2.4.5-RC but I have seen it before on 2.4.4.

Has anybody else seen this?

[provels]

@IsaacFL There are many instances of "time drift" documented in Hyper-V. Try disabling time sync in Integration Services. Let NTP continue to set pfSense's time. https://www.bing.com/search?q=hyper-v+time+drift

[IsaacFL]

@provels said in Log Entries with Date in the Future:

@IsaacFL There are many instances of "time drift" documented in Hyper-V. Try disabling time sync in Integration Services. Let NTP continue to set pfSense's time. https://www.bing.com/search?q=hyper-v+time+drift

I had already done that.

[provels]

@IsaacFL What else have you tried? Bounce NTP? Do the times ever sync, then drift?

[IsaacFL]

@provels what I have been trying was fooling with the NTP service. I tried different pools, settings, etc.

It seems to be fine most of the time, but then I will notice it, and usually I just restart NTP service and it is ok.

It is something that unless you are looking for it, since you kind of just accept the dates and times in the logs.

I only started watching for it, when I saw some NTP entries in the log about clock not synchronized.

kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

[provels]

@IsaacFL Do either of the times match the host time? Does the host use the same time NTP source? FWIW, I also see the same error in the NTP logs at various intervals, as well as plenty of "Unexpected origin timestamp xxxxx.xxxxx does not match aorg 00000.00000 from xx" messages.

[IsaacFL]

@provels The host was using time.windows.com as the ntp source. The time seems to be correct. I changed the host ntp to 2.us.pool.ntp.org so it could also use ipv6.

I haven't been able to find a pattern, so just trying to change random things.

[provels]

@IsaacFL I see on mine that the Windows Time Service only checks once a week. That can be changed in Registry.
Does the log time seems to match the host time when it gets out of whack? Might be something to monitor. Maybe just a Hyper-V "thing". From what I've read, probably better to keep Time Sync turned on in Integration Services.

[IsaacFL]

@provels I just checked and my Windows Time Service is much more often.

Currently it is saying that the last sync at 2:12 and next sync at 2:29.

I am using Hyper-V Server 2019 Core (no gui)

It seems to be stable now, so not sure what else to look at.

You said you have read that it is better to keep Time Sync "on" in integration services?

I have read the opposite, but never a good reason either way. Mine are currently off.

[IsaacFL]

I have turned "on" Time Sync in Integration Services and rebooted the router. So far everything looks good.

[provels]

@IsaacFL Is this a domain or just a workgroup? I could see a problem if you have a domain and your DC is a time server as well. That could start a loop between the host and the DC if VMs are looking at the DC and the host is controlling the VMs. But that shouldn't affect pfSense and what you saw. Seems like the logs are using a different time source and I suspect it could be the host.
PS - I also changed my host (2012R2) to update hourly.

[provels]

@IsaacFL This is interesting. After restarting NTP a couple of hours ago, and Time Sync off on the VM, I see this:

[IsaacFL]

@provels it is a single workgroup host with pfSense and 2 Linux VMs.

[IsaacFL]

@provels

I think that the setting to have the Time Synchronization enabled in Integration Services fixes this.

Since I enabled this setting, I have only seen the clock unsynchronized error at reboot.