Port 123 NTP – Free, Online, Private

What listens on 123

Port 123 is NTP. The IANA name is ntp, Network Time Protocol, RFC 5905. The exchange is UDP. A client sends a request and the server answers from the same port, which is why stateful firewalls sometimes need an explicit rule even though the packet is small. IANA lists TCP as well. The protocol you will see is UDP. NTP can be a client only, talking out to a pool, or a server that answers your fleet. Those are different listeners. A machine that only syncs its own clock may not listen at all. It sends from an ephemeral port to the upstream's 123, or it also uses 123 as its source, depending on the daemon.

The IANA service name is ntp: Network Time Protocol. The practical transport is UDP. The checks below use UDP. A UDP socket has no listen state in the TCP sense, so lsof will not show -sTCP:LISTEN and nc cannot complete a handshake. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 123

Service notes for port 123: the IANA name is ntp (Network Time Protocol), and the program people mean is NTP. UDP 123 is the IANA ntp port. Clients and servers both use it, and a TCP probe will not tell you if time sync works. An open NTP server is a reflection amplifier. The monlist command was the historical one. Close the server to the internet if you do not intend to serve time to the internet. Clients should talk to a small set of upstreams, not to an unfiltered world. Authentication, where you need it, is a MAC inside the NTP packet, not TLS on this port. NTS is a different design. Do not assume a host with UDP 123 open is a friendly pool member. Confirm the configuration. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 123, you are on the wrong page.

Testing NTP with nc -vzu reports almost nothing. The packet has to be an NTP request. ntpdate's successor is a real query, or chronyc tracking, or ntpq. A firewall that allows the request out and drops the reply is the classic one-way failure. Another trap is two daemons, systemd-timesyncd and chrony, disagreeing about who owns the clock. Only one should manage it. Another is a server listening on 123 because a package enabled it, on a host that was supposed to be a client.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 123 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. Look for UDP 123 if you intend to serve time. A client-only host may show no listener, which is fine. From outside, an NTP query that returns a stratum is the test. A TCP connection refused on 123 does not mean NTP is down.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• NTP is UDP. A TCP scan of 123 does not measure it.
• nc -vzu does not send an NTP packet and cannot report a stratum.
• Port 123 open to the world is an amplifier unless you restricted the queries.
• TCP 123 in the IANA registry is not the transport chrony and ntpd use.

Linuxsudo ss -lpun 'sport = :123'
sudo lsof -nP -iUDP:123

macOSsudo lsof -nP -iUDP:123
netstat -anv -p udp | grep '\.123[^0-9]'

Windowsnetstat -ano | findstr :123
Get-NetUDPEndpoint -LocalPort 123

Remotenc -vzu host 123