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.
Note
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.
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”.
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:
Type—number 1 for local on-board clock.Unit—number 0 as the first (the only) unit of local on-board clock.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.
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.