NTP server, port not open

So, I'm trying to install an NTP server on this Windows 10 Home computer. I've tried various tutorials to enable w32time's server mode, and then when that failed I eventually installed Meinberg NTP, to no avail. So here's the thing: the services claim they are working properly, but the NTP port (123) remains closed. I have turned off the firewall. I have no other security software installed that I know of. Here's a log: (Note that the service stops and starts in the middle of the logfile because I rebooted the computer.)

C:\Program Files (x86)\NTP>cat log\log.log
11 Jun 15:30:36 ntpd[3228]: ntpd 4.2.8p15-o Jun 25 14:45:34 (UTC+02:00) 2020  (2): Starting
11 Jun 15:30:36 ntpd[3228]: Command line: C:\Program Files (x86)\NTP\bin\ntpd.exe -U 3 -M -g -c C:\Program Files (x86)\NTP\etc\ntp.conf -l C:\Program Files (x86)\NTP\log\log.log
11 Jun 15:30:36 ntpd[3228]: ----------------------------------------------------
11 Jun 15:30:36 ntpd[3228]: ntp-4 is maintained by Network Time Foundation,
11 Jun 15:30:36 ntpd[3228]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
11 Jun 15:30:36 ntpd[3228]: corporation.  Support and training for ntp-4 are
11 Jun 15:30:36 ntpd[3228]: available at https://www.nwtime.org/support
11 Jun 15:30:36 ntpd[3228]: ----------------------------------------------------
11 Jun 15:30:36 ntpd[3228]: Raised to realtime priority class
11 Jun 15:30:36 ntpd[3228]: Clock interrupt period 15.625 msec
11 Jun 15:30:36 ntpd[3228]: Performance counter frequency 10.000 MHz
11 Jun 15:30:36 ntpd[3228]: proto: precision = 0.100 usec (-23)
11 Jun 15:30:36 ntpd[3228]: basedate set to 2020-06-18
11 Jun 15:30:36 ntpd[3228]: gps base set to 2020-06-21 (week 2111)
11 Jun 15:30:36 ntpd[3228]: Listen and drop on 0 v6wildcard [::]:123
11 Jun 15:30:36 ntpd[3228]: Listen and drop on 1 v4wildcard 0.0.0.0:123
11 Jun 15:30:36 ntpd[3228]: Listen normally on 2 Wi-Fi [fe80::c99b:cdce:96ea:21bf%14]:123
11 Jun 15:30:36 ntpd[3228]: Listen normally on 3 Wi-Fi 192.168.1.153:123
11 Jun 15:30:36 ntpd[3228]: Listen normally on 4 Loopback Pseudo-Interface 1 [::1]:123
11 Jun 15:30:36 ntpd[3228]: Listen normally on 5 Loopback Pseudo-Interface 1 127.0.0.1:123
11 Jun 15:34:13 ntpd[3228]: SCM requests stop (system shutdown)
11 Jun 15:34:13 ntpd[3228]: ntservice: The Network Time Protocol Service is stopping.
11 Jun 15:34:36 ntpd[4696]: ntpd 4.2.8p15-o Jun 25 14:45:34 (UTC+02:00) 2020  (2): Starting
11 Jun 15:34:36 ntpd[4696]: Command line: C:\Program Files (x86)\NTP\bin\ntpd.exe -U 3 -M -g -c C:\Program Files (x86)\NTP\etc\ntp.conf -l C:\Program Files (x86)\NTP\log\log.log
11 Jun 15:34:36 ntpd[4696]: ----------------------------------------------------
11 Jun 15:34:36 ntpd[4696]: ntp-4 is maintained by Network Time Foundation,
11 Jun 15:34:36 ntpd[4696]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
11 Jun 15:34:36 ntpd[4696]: corporation.  Support and training for ntp-4 are
11 Jun 15:34:36 ntpd[4696]: available at https://www.nwtime.org/support
11 Jun 15:34:36 ntpd[4696]: ----------------------------------------------------
11 Jun 15:34:36 ntpd[4696]: Raised to realtime priority class
11 Jun 15:34:36 ntpd[4696]: Clock interrupt period 15.625 msec
11 Jun 15:34:36 ntpd[4696]: Performance counter frequency 10.000 MHz
11 Jun 15:34:36 ntpd[4696]: proto: precision = 0.200 usec (-22)
11 Jun 15:34:36 ntpd[4696]: basedate set to 2020-06-18
11 Jun 15:34:36 ntpd[4696]: gps base set to 2020-06-21 (week 2111)
11 Jun 15:34:36 ntpd[4696]: Listen and drop on 0 v6wildcard [::]:123
11 Jun 15:34:36 ntpd[4696]: Listen and drop on 1 v4wildcard 0.0.0.0:123
11 Jun 15:34:36 ntpd[4696]: Listen normally on 2 Loopback Pseudo-Interface 1 [::1]:123
11 Jun 15:34:36 ntpd[4696]: Listen normally on 3 Loopback Pseudo-Interface 1 127.0.0.1:123
11 Jun 15:34:42 ntpd[4696]: Listen normally on 4 Wi-Fi [fe80::c99b:cdce:96ea:21bf%14]:123
11 Jun 15:34:42 ntpd[4696]: Listen normally on 5 Wi-Fi 192.168.1.153:123

C:\Program Files (x86)\NTP>nmap -p 123 localhost
Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-11 15:35 Central Daylight Time
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00s latency).
Other addresses for localhost (not scanned): ::1

PORT    STATE  SERVICE
123/tcp closed ntp

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

C:\Program Files (x86)\NTP>nmap -p 123 127.0.0.1
Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-11 15:35 Central Daylight Time
Nmap scan report for 127.0.0.1
Host is up (0.00s latency).

PORT    STATE  SERVICE
123/tcp closed ntp

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds

C:\Program Files (x86)\NTP>nmap -p 123 192.168.1.153
Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-11 15:35 Central Daylight Time
Nmap scan report for DESKTOP-CL2NMV9.lan (192.168.1.153)
Host is up (0.00s latency).

PORT    STATE  SERVICE
123/tcp closed ntp

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

C:\Program Files (x86)\NTP>

The service claims to listen on port 123, at many addresses, and netstat -abn agrees that ntpd.exe IS listening on 123 at many addresses, but nmap conversely says that 123 is closed on every local-pointing address I try. Can anybody explain why?

By default, nmap tests TCP ports. The NTP protocol uses only UDP, and the ntpd service only sets up UDP sockets, not TCP.

Those do not interact in any way – probing the TCP port 123 tells you absolutely nothing about what's listening on UDP port 123, nor the other way around.

Additionally, even though you can ask nmap to scan UDP, it won't work as reliably as TCP.

In TCP, you can already tell that a port is definitely "open" vs "closed" if you can establish a connection at TCP level, before getting to speak the application-layer protocol. That is, either you receive an affirmative handshake packet (the SYN-ACK), or negative (RST), or nothing at all, but you learn this from TCP itself. (Nmap's --reason option would show this in more detail.)

In UDP, on the other hand, there is no separate connection establishment – you send any packet and it directly goes to the service in question. So if you send an NTP packet and receive a response, you know for sure that the port is "open" in all senses. But if you send something that is not an NTP packet but only a generic probe, then the service might choose to simply not reply!

So with UDP you cannot tell the difference between "no reply because the listener chose to ignore your garbage packet" versus "no reply because there is nothing listening"¹ versus "no reply because the firewall dropped the packet before it reached the listener".

To determine whether a UDP socket exists, use netstat; and to determine whether the socket responds to valid NTP queries use an actual NTP client (such as ntpdate -q, sntp, or w32tm /monitor).

¹ (In theory, if there was nothing listening to a UDP port, you would normally receive an ICMP "Port Unreachable" error. In practice, Windows Firewall operates in so-called "stealth mode" where ports without a listener will not produce any response at all, neither RST for TCP nor ICMP for UDP, even if the port is allowed by rules. If you want, this can be disabled.)