Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    ip_block.log timestamp lagging behind

    Scheduled Pinned Locked Moved pfBlockerNG
    2 Posts 2 Posters 211 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      milonic
      last edited by

      Hi Guys,

      Have an odd issue with the logs in ip_block.log having an incorrect timestamp.

      This worsens gradually over time.

      If I disable pfBlockerNG, then re-enable it, it resets the time and timestamps are correct again, then over the next few hours the time stamps begin to shift. After about 24 hours, the logs are couple of hours behind.

      I have checked that the logs are running in real time and appear correct, it's literally the timestamp that is wrong and shifting.

      Anybody know what this could be?

      Thanks very much

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG Offline
        Gertjan @milonic
        last edited by

        @milonic

        Running processes, like syslog, don't keep their own time. The use a system call to get the exact time when needed.
        That time, you can see it on the command line, just type

        date
        

        That is the "time stamp" syslog uses when it writes a log line.

        The time is normally counted by a real time clock on the system motherboard. This chip, or the power (remember the famous BIOS RAM battery - it's the same ?)
        Added to that, pfSense processes a ntp = a real time service, so even if the local real time facilities is bad or worse, the system will will get synced every minute or so so it compensates for the loss ( normally less then some nano seconds )

        You have the ntp service activated, right ? By default, it is.
        Just checking : Status > NTP :

        3ac5ce55-f1a7-491f-b828-6768ee125630-image.png

        The NTP is normally configured with host or pool name - I use

        a9428efe-3b28-4b96-b6b7-8493eeaf70b3-image.png

        and this host name points to a pool with mixed IPv4 and IPv6 IPs.
        One is chosen, and the others are backups.

        If you managed to find a pfBlockerng IP list that has these (time server) IPs on the list, and you use the list to block for outgoing connection, then yeah, you've aligned the nearly impossible :
        Using a device with a bad real time clock - this happens more often nthen you thing, stuff just dies .... that's normal.
        Adding extra software (pfBLockerng), and use it to block IP that you actually need : the time server your NTP has selected... now the system time will derail.

        And yes, a good accurate time isn't that important for syslogging (that is, I would consider it a security issue), but becomes very important for simple DNS requests (DNSSEC)à ... or just TLS, also used by pfSense itself.

        So : pfBlockerng : check your IP feeds you've chosen. You should always do this. Just think about it : what happens if you start to use that list that contains all the windows update IP's of Microsoft - and you use this list for blocking outbound connection ? Your PC will not receive any updates anymore, as it can't contact to 'Microsoft' anymore. That's ... dono, not great ?!
        Or you got the list that contains all the IPs of the servers that contain the lists of all the other IP lists and DNSBL (yes, that has been done already) : pfBlocker can't download (update) the other lists anymore ... also great ...
        So, to make a long story short, sorry to say, but do not trust anything that comes from the internet. Use it, and check it. If doubts, don't use it.

        With pfBlockerng taken care of, your NTP server should now sync up your real time.

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.