It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda CloudGen Firewall

This Firmware Version Is End-Of-Support

Documentation for this product is no longer updated. Please see End-of-Support for CloudGen Firewall Firmware for further information on our EoS policy.

Best Practice - How to Handle Incorrect Time Settings

  • Last updated on

The following article provides step-by-step information on how to solve problems involving time drift on different Barracuda CloudGen Firewall units.

Introduction

Incorrect time settings on a Barracuda CloudGen Firewall box will, among other things, result in falsified statistics data. This falsification is even of more concern if the box is CC-administered. Time settings on CC-administered boxes and on the CC itself must run in a synchronized manner so that several of the functions described below operate correctly. Usually, NTP is used to guarantee this. A deviation in time settings can occur if the administrator changes date and time manually or if the BIOS clock drifts while NTP is not available. Box time that lags behind the actual or CC time is a minor problem because, in this case, the system's self-healing process will provide readjustment soon after having reset box time settings manually to the correct values (see sections below).

The consequences of box time running ahead of the actual time or CC time are more severe. The larger the drift, the greater your repairs will be. The following solutions are possible, depending on whether you expect the statistics data to be correct on a quantity basis or correct on time entries:

Self-healing for Quantitative Preference

At the start of a new day, cstatd checks a file's date header to see if current files are to be switched. Files currently in active use will be transferred into a historical file with corresponding date ending if their header date lies in the past. Assuming box time settings are behind, the statistics files will be transferred to a historical file on the next day and "self-healing" will be completed. The statistics files will lack some time entries. Assuming box time settings are ahead, you have corrected these time settings manually. cstatd comes upon a file containing a future date and will likewise leave it at this date, then continue using it for statistics writing until the header date is equal with the actual date. When the file is then switched, it will contain data with diverging time entries of more than one day. "Self-healing" is completed, and a new day file is written.

Even on CC-administered boxes, there may not be a need for further manual corrections concerning the reorganisation of statistics files. After having adjusted the time settings on the box, wait for the next dstats process. This will detect toSend files with a future time stamp in /var/phion/dstats/ which have not yet been delivered to the CC (which means that no masterAccept file is available). The dstats process will remove these files and recreate them.

Manual Correction for Time Preference

For readjustment, the following steps are to be undertaking when diverging time entries in statistics and logging files should be avoided:

Required Actions on the Barracuda CloudGen Firewall:

Step 1: Statistics

  1. Block cstat. (For more information, see below sections).
  2. Delete all sub-folders and files in /var/phion/stat/.
  3. Delete all files with future timestamp in /var/phion/dstats/.
  4. Set the correct time on the box.
  5. Restart the NGFW Subsystem to assure that all subprocesses resume the correct time settings.

Step 2: Log Cache

  1. Block logd. (For more information, see below sections).
  2. Delete subfolders and files in /var/phion/logcache/.
  3. Set the correct time.

Step 3: Logs

  • If possible, delete subfolders and files in /var/phion/logs/.
  • If deleting is not possible, move the contents from /var/phion/logs/ to another directory.
  • If no action is taken, querying the statistics files with the Barracuda Firewall Admin GUI will cause timeline events to be incorrectly displayed later. Moreover, the cache files will continue to contain duplicate entries, even after the time settings have been adjusted.

If the box was running for one day with wrong time settings, you should check directory /var/phion/dstats.

On CC-administered boxes, do not delete statistics with time stamps smaller or equal to the highest masterAccept time stamp. These statistics have already been collected by the CC, and they will be overwritten with the new files if these have a smaller time stamp.

In Addition to the Actions on the Box, Complete the Following on the CC:

Step 4:  Main Statistics

  1. Block dstatm. (For more information, see below sections).
  2. Delete files with a wrong time stamp in subfolders of /var/phion/mainstat/.
  3. Delete toSend-files with a wrong time stamp in /var/phion/dstats/.
  4. If present, delete the folder /var/phion/dstats/tmp/.
  5. Set the correct time.

Further Issues

Especially on CC-administered boxes, time drift might cause other problems as well. Below you will find a brief summary of known issues and instructions on how to correct them.

Licenses

False time settings can lead to incorrect license handling. For example, licenses might not yet be valid even though they should be, or they can lose their validity too early. Licenses of CC-administered boxes cannot be validated correctly against the CC if the time difference between these two systems is too large. Restarting the Rangeconf service on the CC or the Control service on the administered box is another source of error on incorrectly adjusted systems. The restart will involve a license validation and, if this fails, box licenses might get deactivated immediately.

  1. Move the file /opt/phion/preserve/licstamp on the administered box to another place.

    The services will be stopped by this action.

  2. Set the correct time.
  3. Restart the Rangeconf service on the CC.
  4. Restart the Control service on the box.
Time Restrictions Defined by Firewall Rulesets

With incorrect time settings, the restrictions will take effect at the wrong time.

  • You must adjust the box time to solve this problem.
Dynamic Firewall Rules

With incorrect time settings, the defined firewall rules will be activated and deactivated at the wrong time.

  • You must adjust the box time to solve this problem.
Access Cache

With incorrect time settings, the date and time entries in the Access cache will be incorrect.

  • You must adjust the box time to solve this problem.
  • In addition to this adjustment, flush the Access cache with the command acpfctrl cache flush all.
Cron Jobs

With incorrect time settings, Cron jobs will be executed at the wrong time.

  • You must adjust the box time to solve this problem.
Mail Gateway

Incorrect time settings will lead to a divergence between email retrieval and the delivery times.

  • You must adjust the box time to solve this problem.
  • If there are still many emails in the queue that you wish to be stamped with the correct date and time, you can also delete the databases spool.db and history.db in the directory /phion0/spool/. They will then be created again.
System Reboot

With incorrect time settings, a time inconsistency can occur after system reboot. The following error messages are recorded in the dstatm log file: Error *** Unresolvable clock skew detected *** (last run 1066262400, today 1280707200) Error Main stopped. Reason: system time on the Barracuda Firewall Control Center does not match with the time of the last statistics collection. If this is the case, you can reset the timestamp in the header of the dstatm.db file.

  • Check actual value, key, and filename:

    showdb /phion0/dstatm/dstatm.db [...] _header_ 2611|100|1053043200|1066262400|manc shofw.... box|F|range|clean|idle|0|1066276850|10.1.1.1|data collect [...]
  • Set the new parameter to the database for _header_ = key, 2611|100|0|0|manc = value and ./dstatm.db = filename

    setbdb _header_ "2611|100|0|0|manc" ./dstatm.db
  • Check the new parameter in the database:

    showdb /phion0/dstatm/dstatm.db _header_ 2611|100|0|0|manc fw.... box|F|range|clean|idle|0|1066276850|10.1.1.1|data collect

For more information, see: Logging of Clock Skew Events.