When your NTP server shows all remote servers as .INIT. with stratum 16 in ntpq -pn output, it indicates a complete failure to synchronize with upstream time sources. The key indicators are:

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 31.135.95.60    .INIT.          16 u    - 1024    0    0.000    0.000   0.000

The firewall rules show potential issues with UDP port 123 access. While you've added rules for TCP port 123, NTP primarily uses UDP:

# iptables -L -n -v | grep 123
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:123
  204 15504 DROP       udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            udp dpts:0:1023

Use ntpdate -d to test connectivity to specific servers. Successful output should look like:

# ntpdate -d 95.213.132.250
transmit(95.213.132.250)
receive(95.213.132.250)
server 95.213.132.250, port 123
stratum 2, precision -21, leap 00, trust 000
offset 0.002733 sec

Start ntpd in debug mode to see real-time connection attempts:

# ntpd -gqd -D 5

Key configuration elements to check in /etc/ntp.conf:

server 0.gentoo.pool.ntp.org iburst
server 1.gentoo.pool.ntp.org iburst
restrict default nomodify nopeer noquery limited kod

Add explicit UDP 123 rules before any DROP rules:

iptables -I INPUT -p udp --dport 123 -j ACCEPT
iptables -I OUTPUT -p udp --sport 123 -j ACCEPT

If ntpd proves problematic, consider chrony as an alternative:

# chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* time.cloudflare.com           3   6    17    36   +152us[ +152us] +/- 18ms

Create a monitoring script to track synchronization:

#!/bin/bash
while true; do
    ntpq -pn
    chronyc tracking || ntpstat
    sleep 60
done

---

When your NTP servers appear stuck in the .INIT state with stratum 16, this indicates they're completely unsynchronized and operating as orphaned time sources. The key diagnostic outputs show:

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 31.135.95.60    .INIT.          16 u    - 1024    0    0.000    0.000   0.000

The iptables rules show potential UDP blocking issues. While port 123 TCP is allowed, the critical UDP NTP traffic might be blocked:

  204 15504 DROP       udp  --  br1    *       0.0.0.0/0            0.0.0.0/0            udp dpts:0:1023

Add explicit UDP 123 allowance before the broad DROP rule:

iptables -I INPUT -p udp --dport 123 -j ACCEPT

The current config uses pool addresses, but we should verify DNS resolution works:

# dig 0.gentoo.pool.ntp.org +short
195.234.191.100
194.190.168.1

Try adding explicit server IPs as fallback:

server 195.234.191.100 iburst
server 194.190.168.1 iburst

Use these diagnostic commands in sequence:

# Check NTP service status
systemctl status ntpd

# Verify port binding
netstat -tulnp | grep 123

# Test basic connectivity
nmap -sU -p 123 0.gentoo.pool.ntp.org

# Force immediate sync attempt
ntpd -gq

When standard fixes fail, enable debugging:

# Stop current NTP service
systemctl stop ntpd

# Run in foreground with maximum verbosity
ntpd -d -n -D 5

Look for these critical messages in debug output:

• "reply from X.X.X.X: Server dropped: no data"
• "receive: Unexpected origin timestamp"
• "no server suitable for synchronization found"

If persistent issues remain, consider:

# Temporary chrony solution
apt install chrony
chronyc sources -v

# Or use systemd-timesyncd
timedatectl set-ntp true
journalctl -u systemd-timesyncd