5. Time Synchronization with NTP

It is very important to keep the correct time and date on all computer systems, including firewalls, internal servers, routers and even workstations. Kernun UTM provides a time synchronization function by means of an NTP server.

Kernun UTM's NTP server allows two functions: to synchronize the local time with a remote NTP server, and to serve this time data to the local systems. It uses the NTP protocol version 4, but retains compatibility with versions 3, 2 and 1 of the NTP protocol. It can play the client and server role at the same time. Thus, in a typical scenario, Kernun UTM's NTP server exchanges NTP messages with a few public time servers in order to keep its own time and date synchronized, while offering time synchronization to the whole local network.


Local time zone of the Kernun UTM system is set in the console during the first boot, see Section 5.2, “Initial Configuration”.

From now on, we will assume that the initial configuration file is loaded in the GUI, as shown in Section 2, “The Initial Configuration”. To define NTP server parameters, we add a new ntp section at the system level, for instance after the ssh-keys section. As a minimum, we need to define one server in an item within the ntp section, ns2.tns.cz in our example. Furthermore, we want to let the internal systems synchronize their time with Kernun UTM, which is achieved by adding an extra restrict item. We use a reference ^system.INT.ipv4.net to specify our local network; in more complex topologies, we would have to repeat the restrict item and specify internal networks explicitly or using variables. The nopeer and noquery flags of the restrict item are used to allow only client synchronization requests. Figure 5.22, “Minimum NTP server configuration” shows the relevant part of configuration.

Figure 5.22. Minimum NTP server configuration

Minimum NTP server configuration

Reliance on a single external time server may lead to time synchronization outages. Therefore, it is quite common to use more than one time server. The server item can be repeated, which results in a stabler configuration. Moreover, if there are more firewalls or parallel network servers, it is sometimes beneficial to let them know about each other's NTP server, acting together as peers. An NTP peer is not an authoritative source of time data, but may serve for minor time corrections upon Internet blackouts. We achieve this effect by specifying another NTP server with a peer item within the ntp section, as shown in Figure 5.23, “Peer for NTP server”.

Figure 5.23. Peer for NTP server

Peer for NTP server

If the drift-file item is used, Kernun UTM's NTP server attempts to compute the error in the intrinsic frequency of the local on-board clock. The item must be accompanied with a filename, e.g. /var/ntp.drift. The NTP server also includes support for local reference clocks, if available.[27] The on-board system clock itself may be used as a reference clock. An example of its use is depicted in Figure 5.24, “On-board clock with NTP server”. The clock item accepts three parameters:

  1. Type—number 1 for local on-board clock.

  2. Unit—number 0 as the first (the only) unit of local on-board clock.

  3. Stratum—the distance in hops from an accurate authoritative time source; for the local on-board clock, we use number 10 to make it higher than standard Internet NTP servers.

Figure 5.24. On-board clock with NTP server

On-board clock with NTP server

The resulting configuration file is available among Kernun UTM samples under the name ntp.cml in /usr/local/kernun/conf/samples/cml.

[27] Currently, Kernun UTM appliance does not allow for optional hardware reference clock delivery, but this is subject to future changes.