4

I'm trying to get some sort of time synchronization configured for a Ubuntu server. The server is behind a cloud-provider-stateless firewall. Through some trial and error I found out that in order for ntp to work, I have to open the incoming UDP port 123.

Then I read that using systemd-timesyncd is preferred nowadays, so I tried switching over to that. But that did not work. The service log was full of

systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com).
systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.94.4:123 (ntp.ubuntu.com).

Only after I also whitelisted the ephemeral UDP ports 32768–65535 in the firewall did this start to work:

systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

Is opening that range of ports really necessary to operate systemd-timesync?

Edit in response to @Jesus-Loves-You's response below. The higher ports should not be necessary, but in my case, for some reason, they clearly are. See the log of the systemd-timesync service (annotated by me with #):

# Before I enabled the 32786+ ports
May 21 11:49:21 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.198:123 (ntp.ubuntu.com).

# After I enabled the ports
May 21 11:49:06 myhost systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

# After I disabled them again. Note that there are no log entries inbetween for almost
# three days. This, imo, pretty much proves that the ports are required.
May 24 09:29:34 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com).

Further information about the port:

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:42212           0.0.0.0:*                           2656121/systemd-tim

Looks like 42212 is the port where the service expects the communication to happen. But after a couple of minutes, when the next polling occurs:

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:37240           0.0.0.0:*                           2656121/systemd-tim

Now the port changed. And after a couple of minutes it changed again to 51120. So from that I conclude that the service really tries to communicate on random ports each time it attempts the sync.

Improve this question

3 Answers 3

Reset to default
3

It really does use ephemeral ports.

Upon some more research I came across these:

SNTP (RFC 4330) which allows (the more usual) ephemeral source port number

https://iec61850.tissue-db.com/tissue/630

The UDP port number assigned by the IANA to NTP is 123. The SNTP client should use this value in the UDP Destination Port field for client request messages. The Source Port field of these messages can be any nonzero value chosen for identification or multiplexing purposes. The server interchanges these fields for the corresponding reply messages.

This differs from the RFC 2030 specifications, which required both the source and destination ports to be 123.

https://datatracker.ietf.org/doc/html/rfc4330#section-4

So the answer to this whole thing seems to be that systemd-timesyncd is implementing the SNTP protocol, not NTP, and as such uses ephemeral source UDP ports. That is by design. The question now becomes "how to handle ephemeral ports on a stateless firewall" /shrug.

Improve this answer
2

All I had to do on Debian 10 "Buster" and Debian 11 "Bullseye" was to open Outbound UDP Port 123

  • My inbound port 123 is not open.
  • Restarting any service isn't necessary.

Results in /var/log/syslog:

Debian 10:

Sep 23 18:21:19 app systemd-timesyncd[20076]: Synchronized to time server for the first time 194.35.12.189:123 (0.debian.pool.ntp.org).

Debian 11:

Sep 23 18:25:21 post systemd-timesyncd[418]: Initial synchronization to time server 65.21.190.104:123 (0.debian.pool.ntp.org).

Improve this answer
0

I did have exactly the same question. This worked for me (if You are using iptables):

-A INPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate ESTABLISHED -j ACCEPT -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

As far as I understood, systemd-timesyncd is something like a client implementation (https://wiki.archlinux.org/title/Systemd-timesyncd) of ntp simply establishing an outgoing request, so there should be no further adjustments to be made in Your case.
And according to https://www.ietf.org/rfc/rfc5905.txt the necessary port is still port number 123 (UDP)

So answering Your question, no, those higher ports, that You mentioned, are NOT necessary. You did everything right

Maybe You were just missing a service restart?
sudo systemctl restart systemd-timesyncd systemctl status systemd-timesyncd.service timedatectl status

Please notice: if this answer does not really work out in Your case, know that I just had the very same issue. So You are very close to the real answer. Best regards bro

Improve this answer
1
  • Thanks for the answer, I have added an edit to my question proving that the higher ports are really needed. Also, as specified in my question, I am not using iptables but rather a stateless firewall offered by my cloud provider. Due to the firewall being stateless, it is not able to track the communication on iptables level anyway, so your suggestion does not apply here. My understanding about sytemd-timesyncd is the same as yours, which is why I am baffled by this. Note that ntp works in my case - it is only systemd-timesyncd that somehow requires the higher ports opened.
    – Martin Melka
    May 24, 2021 at 9:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .