# Configuration of local NTPD on FreeBSD 13.0



## mar.gorski (Apr 24, 2022)

Hi,
NTPD seems to be simple service, but I found it challenging it doesn't do what I need. Currently local date synchronization works well, however I need to use it as local network service no matter if ntp client has access to Internet or no. No NAT is better.

I have 2 network interfaces:
em0 inet 192.168.0.1 WAN
em1 inet 10.0.0.1 LAN

I need to achieve NTPD listening on 127.0.0.1 and 10.0.0.1 and serving local servers which are disconnected from NAT. Currently it only synchronizes time on server and need to be available as a network service. NTPD should not listen on 192.168.0.1. Also it must be read only for network clients.

In /etc/rc.conf:
`# NTP
ntpdate_enable="YES"
ntp_sync_on_start="YES"
ntpd_enable="YES"`

Service starts, however on all addresses what is wrong (should be for internal use only):
`root     ntpd       52931 21 udp4   *:123                 *:*
root     ntpd       52931 22 udp4   192.168.0.1:123         *:*
root     ntpd       52931 23 udp4   10.0.0.1.1:123          *:*
root     ntpd       52931 26 udp4   127.0.0.1:123         *:*`

I started from simplest possible /etc/ntp.conf:
`server 0.pool.ntp.org # better to use than a single server pool, temporary solution
driftfile /var/db/ntp.drift
listen on 127.0.0.1
listen on 10.0.0.1`

For debugging time I decided to disable firewall. Errors occur no matter if packet filtering is enabled or not.

Issue 1: NTPD listens on wrong addresses. How to achieve listening only on selected addresses?
Issue 2: I am testing connectivity right now. Simple rdate seems to be compatible with NTP (I'm aware that by default it uses legacy time protocol). It responds when I try to connect to local NTPD (from NTPD host shell):
`root@host:/home/mar # rdate -p 10.0.0.1
Sun Apr 24 17:29:49 CEST 2022
root@host:/home/mar # rdate -p 127.0.0.1
Sun Apr 24 17:29:52 CEST 2022`
It doesn't respond via network.

Issue 3: Is it possible to query NTPD using TCP instead? 

What am I doing wrong?

Best regards,
Marcin


----------



## mer (Apr 24, 2022)

NTP is a udp protocol as far as I know.  There may be implementations that work over TCP, but if you look at what the protocol does, TCP doesn't make any sense.

Just to make sure I understand, you want this machine to act as an NTP client on em0 and an NTP server on em1?
By default stock ntpd listens on all ports (except for lo).
Looking at an old ntp.conf I have (I only have ntp client needs, so use openntpd for that), try the following:
remove (or comment out) your "listen on" statements and add
`interface ignore wildcard
interface listen 127.0.0.1
interface listen em1`
The "ignore wildcard" is important from what I recall.


----------



## mar.gorski (Apr 24, 2022)

Yes the NTPD machine is both ntp client (to set correct time on server) and local ntpd cache resolver for a local network. Issue 1 is resolved thank you, service now listen on correct interfaces. Issue 3 might also be considered closed, doing against RFC makes no sense.

I'm aware that TCP session are slow comparing to UDP and this is the reason why DNS also uses UDP. I'm fine with UDP. 

On NTPD server host currently rdate doesn't respond, but NTPD is active on correct UDP ports.
`# rdate -p 127.0.0.1
rdate: Ignoring NTP server with alarm flag set
rdate: Unable to get a reasonable time estimate`

Still struggling with issue 2 - connectivity from local server after changing listen it doesn't respond. Perhaps something more must be added to ntp.conf to make it usable. On remote Linux machine I receive.

Local FreeBSD host want to connect to 127.0.0.1 123 UDP:
`# pkg info | grep rdate
rdate-20150501                 Sets the clock of the local host to the time of another host
# rdate -p 10.1.1.1
rdate: Ignoring NTP server with alarm flag set`

From Linux client:
`sudo ntpdate 10.0.0.1
24 Apr 18:43:20 ntpdate[4504]: no server suitable for synchronization found`


----------



## mer (Apr 24, 2022)

Cool.  Glad we moved you forward a little bit.  TCP/UDP:  it's more "NTP is not going to do TCP according to the RFC".

Looking back at my old ntp.conf, I have the following  (the comment is mine):
`# The following settings allow unrestricted access from the localhost
restrict 127.0.0.1
restrict ::1`

So assuming your LAN clients are all 10.x.y.z, you may be able to modify add:
restrict 10.0.0.1

to allow unrestricted access from the LAN.   I'm running out of options/ideas it's been a while since I set up a server for NTP on my local network, but at least you can search for the "restrict" directive.


----------



## mar.gorski (Apr 24, 2022)

My current ntpd.conf looks like this (when it finally works I should also add nomodify to make it read-only):
`server 0.pool.ntp.org
driftfile /var/db/ntp.drift
interface ignore wildcard
interface listen 127.0.0.1
interface listen em1
restrict 127.0.0.1
restrict 10.0.0.0 mask 255.255.255.0 nomodify`

According to the documentation restrict must be added, however it still doesn't work no matter if package filtering is enabled or not. Still need to read more. ntpdate or rdate on 127.0.0.1 or 10.0.0.1 doesn't receive current time.

Perhaps I should read what is "NTP server alarm flag". Another error on network address 10.0.0.1 is: "rdate: Unable to get a reasonable time estimate". Maybe local drift is not synchronized, but ntpdate during os bootstrap sets correct remote date (configuration attached in first post rc.conf).


----------



## Alain De Vos (Apr 24, 2022)

I sit on a public IP-address without firewall & nat.
My ntp.conf has only one line:

```
server 1.be.pool.ntp.org
```
Is this OK ?


----------



## mer (Apr 24, 2022)

What's the output of "sockstat -ln"?  That will show listening sockets.  But in general, ntpd will set up listening sockets on all interfaces.  If you are not trying to serve time, you may want to rethink it.


----------



## Alain De Vos (Apr 25, 2022)

I only want to serve time to "myself".
But:
sockstat -ln | grep ntp,

```
123      ntpd       74432 20 udp6   *:123                 *:*
123      ntpd       74432 21 udp4   *:123                 *:*
123      ntpd       74432 22 udp6   fe80:.... re0:123 *:*
123      ntpd       74432 23 udp6   ::1:123               *:*
123      ntpd       74432 24 udp6   fe80::1%lo0:123       *:*
123      ntpd       74432 25 udp4   127.0.0.1:123         *:*
123      ntpd       74432 26 udp6   fe80:...:123 *:*
123      ntpd       74432 27 udp4   81.       :123     *:*
123      ntpd       74432 29 udp6   2a02:...:123 *:*
123      ntpd       74432 31 udp6   2a02:...:123 *:*
123      ntpd       74432 32 udp6   2a02:..:123 *:*
123      ntpd       74432 33 udp4   192.168.1.2:123       *:*
```

2a02: ... is a public IPV6 adress.


----------



## Alain De Vos (Apr 25, 2022)

I've updated my ntp.conf. Is this OK ?

```
server 1.be.pool.ntp.org
restrict           127.0.0.1/8
restrict         192.168.0.1/24
interface listen   127.0.0.1/8
interface listen 192.168.0.1/24
```

sockstat -ln | grep ntp:

```
123      ntpd       66329 20 udp6   *:123                 *:*
123      ntpd       66329 21 udp4   *:123                 *:*
123      ntpd       66329 22 udp6   ::1:123               *:*
123      ntpd       66329 23 udp4   127.0.0.1:123         *:*
```


----------



## gpw928 (Apr 25, 2022)

By default, ntpd(8) will listen on all interfaces, except localhost.
There are usually few reasons to change the default ntp.conf(5), because it's got a lot of things that you need.
However, if you want to control the interfaces, ignore them all, and then add in the ones you want:
	
	



```
# allow unrestricted access from the localhost
restrict 127.0.0.1
# ignore all interfaces...
interface ignore wildcard
# except these
interface listen 127.0.0.1
interface listen 10.0.0.1
```
The above works for me.  If it does not work for you, please show us the full ntp.conf and the output of `lsof -ni UDP:123`. [The sockstat mentioned by Alain De Vos is also good.]


----------



## Erichans (Apr 26, 2022)

mar.gorski said:


> [...]
> `# NTP
> ntpdate_enable="YES"
> ntp_sync_on_start="YES"
> ntpd_enable="YES"`


I think you unintentionally missed a "d":

```
ntpd_sync_on_start="YES"
```
However, your set up might have saved you some trouble. Use either:

```
ntpd_enable="YES"
ntpd_sync_on_start="YES"
```
_or_

```
ntpdate_enable="YES"
ntpd_enable="YES"
```

I prefer to use only ntpd(8) over its combined use with ntpdate(8) in this situation (see why). To use `ntpdate` together with `ntpd_sync_on_start="YES"`, as in:

```
ntpdate_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
```
you will have two competing commands both working via NTP but, via different mechanisms and both trying to "quickly" set the time: not advisable.


Why don't you give `ntpdate -d host` a try for your local testing?
ntpdate(8):

```
-d	 Enable the debugging mode, in which ntpdate will go through all
	     the steps, but not adjust the local clock. Information useful
	     for general debugging will also be printed.
```

Perhaps also useful:

 NTP Debugging Techniques
 NTP Debugging Unreachable Time Sources


----------



## cy@ (Apr 26, 2022)

mar.gorski said:


> Hi,
> NTPD seems to be simple service, but I found it challenging it doesn't do what I need. Currently local date synchronization works well, however I need to use it as local network service no matter if ntp client has access to Internet or no. No NAT is better.
> 
> I have 2 network interfaces:
> ...


Where are you getting your time from? ntpd needs to get its time from somewhere, like another ntpd server, a GPS, an atomic clock, or some other time source.


----------



## SirDice (Apr 26, 2022)

cy@ said:


> ntpd needs to get its time from somewhere, like another ntpd server, a GPS, an atomic clock, or some other time source.


Sometimes ISPs or hosting providers will have an NTP service for their customers, if they have use that one. If not, lookup something close: https://www.ntppool.org/en/


----------



## Jose (Apr 27, 2022)

Why didn't you start with the default ntp.conf?


mar.gorski said:


> My current ntpd.conf looks like this (when it finally works I should also add nomodify to make it read-only):
> `server 0.pool.ntp.org`


The comments in the default ntp.conf say `The option `iburst' is used for faster initial synchronization.` Is there some reason why you don't want that?


mar.gorski said:


> `driftfile /var/db/ntp.drift`


This is the default. There's no need for this line


mar.gorski said:


> `interface ignore wildcard`


I wonder what is the difference between `wildcard` and `all`. Alas, the documentation doesn't say:








						Miscellaneous Commands and Options
					

Descriptions of miscellaneous commands and options for configuring NTP.




					doc.ntp.org
				



Any reason why you decided not to use the defaults?

```
restrict default limited kod nomodify notrap noquery nopeer
restrict source  limited kod nomodify notrap noquery
```



mar.gorski said:


> `interface listen 127.0.0.1`


I guess that if you drop the `prefixlen` then the whole address has to match? The documentation is not clear on this point either. I would try `127.0.0.0/8` just to see what happens.


mar.gorski said:


> `restrict 127.0.0.1
> restrict 10.0.0.0 mask 255.255.255.0 nomodify`


Unfortunately these two lines probably don't do anything. You didn't specify a `restrict default`, and the documentation says:


> A default entry is also always present, though if it is otherwise unconfigured; no flags are associated with the default entry (i.e., everything besides your own NTP server is unrestricted).





			Access Control Commands and Options
		


This is what I would use (my actual config uses local NTP servers my ISP provides.)

```
pool 0.freebsd.pool.ntp.org iburst
leapfile "/var/db/ntpd.leap-seconds.list"
restrict default limited kod nomodify notrap noquery nopeer
restrict source  limited kod nomodify notrap noquery
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer notrap
```
EDIT: Forgot the leap seconds file.


----------



## mar.gorski (Apr 30, 2022)

What is practical and easy 4.3 BSD RFC 868 solution served by inetd (both TCP and UDP valid until 2038) works out-of-box and is trivial to setup and debug. rdate as OS date synchronization tool do the job both for NTP and RFC868. I expected NTPD to be the same trivial thing. Finally keep using it and NTPD only for server clock synchronization (which later might be shared by different services). NTPD listens on local addresses, but doesn't respond on any. I found NTPD too complicated to use for private NAT network disconnected from Internet, but working for time synchronization for servers which has NAT. Fortunately RFC 868 is still available.

As work-a-round unlock in inetd.conf:
`time    stream    tcp    nowait    root    internal`
Probably NTPD is perfectly correct, but too complicated to be configured by average user for private network. Probably I should change root on another user.

Current NTPD configuration which works only locally (synchronizes clock) but doesn't provide network time despite the fact ports are open internally and service listens:
`root     ntpd       77050 20 udp4   10.1.1.1:123          *:*
root     ntpd       77050 22 udp4   127.0.0.1:123         *:*`

`# NTP
ntpdate_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"`

Still use NTP to set local time.
`pool 0.freebsd.pool.ntp.org iburst
driftfile "/var/db/ntp.drift"
leapfile "/var/db/ntpd-leap-seconds.list"
interface ignore wildcard
interface listen 127.0.0.1
interface listen 10.1.1.1
restrict 127.0.0.1
restrict 10.1.1.0 mask 255.255.255.0 nomodify notrap`

Response:
`# ntpdate -d 127.0.0.1
 1 May 03:09:05 ntpdate[12839]: ntpdate 4.2.8p15-a (1)
transmit(127.0.0.1)
receive(127.0.0.1)
transmit(127.0.0.1)
receive(127.0.0.1)
transmit(127.0.0.1)
receive(127.0.0.1)
transmit(127.0.0.1)
receive(127.0.0.1)
127.0.0.1: Server dropped: strata too high

server 127.0.0.1, port 123
stratum 16, precision -21, leap 11, trust 000
refid [.], root delay 0.000000, root dispersion 0.000000
reference time:      (no time)
originate timestamp: e6185c38.1a95b1b1  Sun, May  1 2022  3:09:12.103
transmit timestamp:  e6185c38.1a8d16d4  Sun, May  1 2022  3:09:12.103
filter delay:  0.0XXXX    0.0XXXX    0.0XXXX    0.0XXXX   
               ----       ----       ----       ----      
filter offset: +0.000008  -0.000001  +0.000001  +0.000003 
               ----       ----       ----       ----      
delay 0.02571, dispersion 0.00000, offset +0.000001

 1 May 03:09:12 ntpdate[12839]: no server suitable for synchronization found`

Needed to update leap file via /etc/rc.d/ntpd onefetch because it is not created by daemon. Used only for local synchronization. For network time sharing legacy protocol is used and works well.

As I understand for connect NTP connection I should open on both sides (client and server) 123 UDP port (https://datatracker.ietf.org/doc/html/rfc5905):
`srcport: UDP port number of the server or reference clock.  This
   becomes the destination port number in packets sent from this
   association.  When operating in symmetric modes (1 and 2), this field
   must contain the NTP port number PORT (123) assigned by the IANA.  In
   other modes, it can contain any number consistent with local policy.

   dstaddr: IP address of the client.  This becomes the source IP
   address in packets sent from this association.

   dstport: UDP port number of the client, ordinarily the NTP port
   number PORT (123) assigned by the IANA.  This becomes the source port
   number in packets sent from this association.`








						RFC ft-ietf-ntp-ntpv4-proto: Network Time Protocol Version 4: Protocol and Algorithms Specification
					

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified...




					datatracker.ietf.org
				




Prefer slow, plain legacy TCP services.

Offtop:
What is interesting NTPD seems to bypass PF firewall (simple block in rule) because 123 UDP port is not opened on computer which uses synchronization (external WAN interface). UDP is stateless so response port seems to be needed to be available explicitly. Also DHCP. Probably default contract of all firewall vendors?


----------

