EN FR

NTP Blocked by the Firewall: Diagnosing UDP Port 123

Updated July 2026 · Opening UDP 123 is the easy part — here is what to check when NTP still refuses to sync

Understanding NTP & Firewalls

Why NTP Gets Blocked

IssueCauseImpact
Outbound blocked Firewall blocks UDP 123 to external servers Cannot sync with any NTP server
Inbound blocked Stateful firewall drops response packets Timeout errors, "unreachable" status
NAT issues Source port changes during NAT translation Symmetric NAT breaks NTP
ISP blocking Some ISPs block UDP 123 entirely Must use alternative methods

NTP Ports: Is There More Than One?

Classic NTP uses a single port: UDP 123, as its default and only transport port, for both the source and the destination. There is no TCP fallback and no secondary port — so a host that cannot reach UDP 123 cannot synchronize at all.

The exception is NTS (Network Time Security), the authenticated variant. NTS performs a key exchange over TCP 4460 first, then carries the actual time packets over UDP 123 as usual. If you are deploying NTS and only opened 123, the key exchange fails before a single time packet is sent — a failure mode that looks exactly like a blocked firewall. See how NTS works in production if that is your case.

Inbound or Outbound: Which Direction Do You Open?

It depends on what the machine is, and getting this wrong is the most common cause of a rule that looks correct but changes nothing:

  • NTP client (a server or workstation that only reads the time): outbound UDP 123 only. The replies come back on an established flow, so a stateful firewall lets them in without an explicit inbound rule.
  • NTP server (a machine other hosts query): inbound UDP 123 as well, otherwise queries never reach the daemon.

If you opened inbound on a pure client, you have widened your exposure without fixing anything — and if your firewall is stateless, the missing piece is the return path, not the outbound rule. The sections below give the exact commands per platform.

Linux: iptables Configuration

Allow Outbound NTP (Client Mode)

# Allow outbound NTP requests root@server:~# iptables -A OUTPUT -p udp --dport 123 -j ACCEPT # Allow inbound NTP responses (stateful) root@server:~# iptables -A INPUT -p udp --sport 123 -j ACCEPT # Or use connection tracking (recommended) root@server:~# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Allow Inbound NTP (Server Mode)

# If running as NTP server, allow incoming queries root@server:~# iptables -A INPUT -p udp --dport 123 -j ACCEPT root@server:~# iptables -A OUTPUT -p udp --sport 123 -j ACCEPT

Save Rules Permanently

# Debian/Ubuntu root@server:~# iptables-save > /etc/iptables/rules.v4 # RHEL/CentOS (legacy) root@server:~# service iptables save

Linux: firewalld (RHEL/CentOS/Fedora)

Enable NTP Service

# Allow NTP permanently root@server:~# firewall-cmd --permanent --add-service=ntp # Reload firewall root@server:~# firewall-cmd --reload # Verify root@server:~# firewall-cmd --list-services ssh dhcpv6-client ntp

Or Open Port Directly

# Add UDP port 123 root@server:~# firewall-cmd --permanent --add-port=123/udp root@server:~# firewall-cmd --reload

Zone-Specific Configuration

# Add to specific zone root@server:~# firewall-cmd --zone=public --permanent --add-service=ntp root@server:~# firewall-cmd --reload

Linux: ufw (Ubuntu/Debian)

Simple Configuration

# Allow NTP outbound and inbound root@server:~# ufw allow 123/udp # Check status root@server:~# ufw status numbered Status: active To Action From -- ------ ---- [ 1] 123/udp ALLOW IN Anywhere [ 2] 123/udp (v6) ALLOW IN Anywhere (v6)

Allow Only Outbound (More Secure)

# For client-only systems (outbound only) root@server:~# ufw allow out 123/udp

Restrict to Specific Servers

# Only allow NTP to specific server root@server:~# ufw allow out to 195.154.XXX.XXX port 123 proto udp root@server:~# ufw allow in from 195.154.XXX.XXX port 123 proto udp

Windows Firewall

PowerShell Commands

# Allow NTP outbound PS C:\> New-NetFirewallRule -DisplayName "NTP Outbound" -Direction Outbound -Protocol UDP -RemotePort 123 -Action Allow # Allow NTP inbound (for responses) PS C:\> New-NetFirewallRule -DisplayName "NTP Inbound" -Direction Inbound -Protocol UDP -LocalPort 123 -Action Allow

GUI Method

  1. Open Windows Defender Firewall with Advanced Security
  2. Click Inbound RulesNew Rule
  3. Select PortUDPSpecific local ports: 123
  4. Select Allow the connection
  5. Apply to Domain, Private, Public as needed
  6. Name: "NTP UDP 123"
  7. Repeat for Outbound Rules

Check Windows Time Service

# Verify Windows Time service is using network C:\> w32tm /query /status C:\> w32tm /query /peers

Enterprise Firewalls

Cisco ASA

! Allow NTP from internal to external access-list OUTSIDE_IN extended permit udp any any eq 123 access-list INSIDE_OUT extended permit udp any any eq 123

Palo Alto

# Security Policy Source Zone: trust Destination Zone: untrust Application: ntp Service: application-default Action: Allow

pfSense / OPNsense

  1. Go to Firewall → Rules → LAN
  2. Add rule: Protocol UDP, Destination Port 123
  3. Action: Pass
  4. Description: "Allow NTP"

Testing NTP Connectivity

Test UDP Port 123

# Using netcat root@server:~# nc -vzu ntp.rdem-systems.com 123 Connection to ntp.rdem-systems.com 123 port [udp/ntp] succeeded! # Using nmap root@server:~# nmap -sU -p 123 ntp.rdem-systems.com PORT STATE SERVICE 123/udp open ntp

Test NTP Protocol

# Using ntpdate (query mode) root@server:~# ntpdate -q ntp.rdem-systems.com server 195.154.XXX.XXX, stratum 1, offset 0.000234, delay 0.02563 14 Jan 11:30:45 ntpdate[12345]: adjust time server 195.154.XXX.XXX offset 0.000234 sec # Using sntp root@server:~# sntp ntp.rdem-systems.com

Diagnose Blocked NTP

# Check for firewall drops in logs root@server:~# dmesg | grep -i "DROP.*123" root@server:~# journalctl -k | grep -i "DROP" # Trace NTP packets root@server:~# tcpdump -i any port 123 -nn

Frequently Asked Questions

Does NTP use TCP or UDP?

UDP. Classic NTP runs over UDP port 123 only and has no TCP mode. The one exception is NTS, which opens a TCP 4460 key exchange before falling back to UDP 123 for the time packets themselves — see NTP Ports: Is There More Than One? above for what that means for your rules.

The port 123 is open but NTP still won't synchronize. Why?

Because an open port is only the first of four conditions. The packet still has to survive NAT translation, return on the source port the client expects, and be accepted by the daemon's own restrict rules. Work through them in order: start with the counter check on your firewall rule — if it shows zero packets, nothing is even reaching it — then move to the packet-level diagnosis.

Should I open port 123 inbound or outbound?

Outbound only if the machine is an NTP client, inbound as well only if it serves time to other hosts. Opening inbound on a client widens your exposure without fixing anything. The inbound vs outbound section above sets out both cases and the stateless-firewall exception.

What is the default NTP port?

UDP 123, for both source and destination — NTP is one of the few protocols that uses the same port on both ends, which is precisely why NAT and stateless firewalls break it in ways a simple port test won't reveal. The NTP ports section explains the consequence.

Test Your Configuration

After configuring your firewall, verify everything works:

Run NTP Diagnostics Daemon Issues

See also: CLI testing commands · Why opening UDP/123 is required for NIS 2 compliance

Production use case: full NTP sync audit — 4.2s drift fixed (FR)