Skip to main content.

Running an NTP server


Live demo in BSD Now Episode 023 | Originally written by TJ for | Last updated: 2015/05/01

NOTE: the author/maintainer of the tutorial(s) is no longer with the show, so the information below may be outdated or incorrect.

So it's new year's eve and you're counting down the seconds to midnight with all your other lonely friends on IRC. But wait, you start celebrating 5 seconds before their clocks hit 12:00! Everyone laughs at you, what an embarrassing situation. You won't have to worry about that happening if you have your clock synced with a Network Time Protocol server. This tutorial will show you how to both keep your client machines synced, as well as how to run your own NTP server and help out the community. Currently, there are two main NTP daemons, or "ntpd" programs you can choose from. We won't be detailing how to use a GPS device, only the software. A big reminder: whichever implementation you use, please keep it up to date. Don't let security flaws turn your server into a bot for DDoS attacks.

ISC NTP server

The NTP daemon from ISC is the reference implementation, and has gone through decades of development. It's installed by default in FreeBSD, but you need to edit a few files to get it running. First I'll be showing you how to open an NTP server to your LAN, then how to run a public one. Let's start by editing the configuration file.

# vi /etc/ntp.conf

It has lots of comments and information that you can read through. As of 10.0, the only uncommented lines included by default are:

server iburst
server iburst
server iburst
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict -6 ::1

These are the pools that it will query by default and try to sync to. They're mostly volunteer-run servers, but many governments and companies also run their own. The hostnames have multiple IPs and you should automatically get one that's close to your physical location. Stratum 1 servers are the most accurate ones that are connected to the internet. As the number increases, the delay (usually) increases. Turning this default configuration into a server configuration is very simple. Here's a diff for a LAN-only server:

--- ntp.conf    2014-12-27 22:07:31.000000000 -0500
+++ ntp.conf    2014-12-27 22:31:41.000000000 -0500
@@ -43,8 +43,7 @@
 # See
 # for more information.
-restrict default kod nomodify notrap nopeer noquery
-restrict -6 default kod nomodify notrap nopeer noquery
+restrict mask nomodify nopeer noquery notrap
 # Alternatively, the following rules would block all unauthorized access.

This is assuming you're using a network setup - adjust accordingly. You may also want to use the "broadcast" option along with "broadcastclient" for your LAN IPs to reduce some of the load on the server. Don't worry about that if you're going to run an internet-facing one. Now we'll tell ntpd to autostart at boot, sync our clock and get going.

# echo 'ntpd_enable="YES"' >> /etc/rc.conf
# echo 'ntpd_sync_on_start="YES"' >> /etc/rc.conf
# ntpdate
# service ntpd start

Be sure to open UDP port 123 in your firewall for the LAN IPs. You'll also need to set your server's IP as the default for all the clients. For a public, internet facing NTP server, a diff would look more like this:

--- ntp.conf    2014-01-30 21:06:47.000000000 -0500
+++ ntp.conf    2014-01-30 21:12:49.000000000 -0500
@@ -43,8 +43,8 @@
 # See
 # for more information.
-restrict default kod nomodify notrap nopeer noquery
-restrict -6 default kod nomodify notrap nopeer noquery
+restrict default kod nomodify notrap nopeer noquery maxpoll 8
+restrict -6 default kod nomodify notrap nopeer noquery maxpoll 8
 # Alternatively, the following rules would block all unauthorized access.

Open UDP port 123 and point the clients to that server as usual.

OpenBSD NTP server

Officially released on November 1st, 2004, OpenNTPD is an NTP daemon from the OpenBSD project. Due to security, licensing and configuration concerns with the ISC version, the OpenBSD team decided to write their own implementation. Some of its goals include:

  • Be as secure as possible. Code carefully, do strict validity checks especially in the network input path, and use bounded buffer operations. Use privilege separation to mitigate the effects of possible security bugs.
  • Provide a lean implementation, sufficient for a majority. Don't try to support each and every obscure usage case, but cover the typical ones.
  • Try to "Just Work" in the background.
  • Work with just a minimum of configuration.

There is also a portable version, available in FreeBSD's ports and NetBSD's pkgsrc. The file /etc/ntpd.conf is what we need to edit.

# cp /etc/examples/ntpd.conf /etc
# vi /etc/ntpd.conf

It only has one uncommented line by default:


It's recommended to have multiple sources, so we'll add more pools to the file. A few examples (all known to be running BSD) would be:

--- ntpd.conf   Thu Jan 30 21:21:44 2014
+++ ntpd.conf   Sat Feb  1 12:18:36 2014
@@ -7,6 +7,11 @@
 # sync to a single server

+# use some well-known pools to distribute the load
 # use a random selection of NTP Pool Time Servers
 # see

As of 5.7, OpenNTPD supports an "HTTPS constraints" feature. This aims to prevent NTP spoofing attacks by keeping the time within a known reasonable range. To use it, add a line like this one:

contraint from ""

If you want the daemon to listen on all available addresses, add something like:

listen on *

Or, for just the LAN:

listen on

Change it to whatever internal IP address you have. As far as I could tell, OpenNTPD does not support the broadcast/broadcastclient options. You'll need to open UDP port 123 in pf to either your LAN or the whole world, depending on which type of server you want to run. To get OpenNTPD running on OpenBSD, you just need to do:

# echo 'ntpd_flags=""' >> /etc/rc.conf.local
# ntpd -s

If you're on OpenBSD 5.5 or later, you can see some information about your current NTP connections by running:

# ntpctl -sa

4/4 peers valid, clock synced, stratum 2

   wt tl st  next  poll          offset       delay      jitter from pool 
 *  1 10  1    2s   33s         0.440ms    43.557ms     5.154ms from pool 
    1 10  3    9s   30s        -3.770ms    35.914ms     4.645ms from pool 
    1 10  2    7s   32s         1.666ms    84.411ms     3.767ms from pool 
    1 10  1    1s   33s         0.493ms    42.611ms     3.977ms

If you're using pf, you can forcefully redirect all your LAN clients' NTP requests to the server you're running with a line like this in /etc/pf.conf:

pass in quick on $int_if proto udp from any to ! port 123 rdr-to

Otherwise, just point your clients to the IP or domain name of your NTP server.

Helping out

There are some requirements for adding your NTP server to the official pools, so please read over them if you're interested in helping out. If you are doing a public-facing NTP server, avoid using "" in your configuration. Use these instead. There's a public list of servers that you can choose from. It's generally recommended to have five or more. You may also be interested in the NTP mailing lists.

Latest News

New announcement


We understand that Michael Dexter, Brad Davis, and George Rosamond think there should be more real news....

Two Year Anniversary


We're quickly approaching our two-year anniversary, which will be on episode 105. To celebrate, we've created a unique t-shirt design, available for purchase until the end of August. Shirts will be shipped out around September 1st. Most of the proceeds will support the show, and specifically allow us to buy...

New discussion segment


We're thinking about adding a new segment to the show where we discuss a topic that the listeners suggest. It's meant to be informative like a tutorial, but more of a "free discussion" format. If you have any subjects you want us to explore, or even just a good name...

How did you get into BSD?


We've got a fun idea for the holidays this year: just like we ask during the interviews, we want to hear how all the viewers and listeners first got into BSD. Email us your story, either written or a video version, and we'll read and play some of them for...

Episode 251: Crypto HAMMER


Direct Download:MP3 AudioVideo This episode was brought to you by Headlines DragonflyBSD: Towards a HAMMER1 master/slave encrypted setup with LUKS I just wanted to share my experience with setting up DragonFly master/slave HAMMER1 PFS's on top of LUKS So after a long time using an Synology for my NFS needs, I...

Episode 250: BSDCan 2018 recap


Direct Download:MP3 AudioVideo This episode was brought to you by Headlines TrueOS to Focus on Core Operating System The TrueOS Project has some big plans in the works, and we want to take a minute and share them with you. Many have come to know TrueOS as the “graphical FreeBSD” that makes...

Episode 249: Router on a stick


Direct Download:MP3 AudioVideo This episode was brought to you by Headlines ZFS and DTrace update lands in NetBSD merge a new version of the CDDL dtrace and ZFS code. This changes the upstream vendor from OpenSolaris to FreeBSD, and this version is based on FreeBSD svn r315983. + r315983 is from...

Episode 248: Show me the Mooney


Direct Download:MP3 AudioVideo This episode was brought to you by Headlines DragonFlyBSD: release52 (w/stable HAMMER2, as default root) DragonflyBSD 5.2.1 was released on May 21, 2018 > Big Ticket items: > Meltdown and Spectre mitigation support Meltdown isolation and spectre mitigation support added. Meltdown mitigation is automatically enabled for all Intel cpus. Spectre mitigation must be enabled...