I’ve noticed that my Ubiquiti UDM PRO Max, using its default firewall settings, is blocking an IP address from the pool.ntp.org NTP server pool. I’m unsure if this is a rogue NTP server or if it’s being flagged for another reason (e.g., a false positive in the firewall’s rules or an external blocklist). I’d like to report this to the NTP Pool administrators to ensure it’s investigated and, if necessary, removed from the pool.
For privacy and security reasons, I’d prefer not to share the IP address publicly. Could someone advise on the best way to report this discreetly? Is there a specific contact or trusted administrator I can reach out to privately to share the IP address and details?
Additionally, if anyone has tips on how to verify whether this IP is a legitimate NTP server or why my UDM PRO Max firewall might be blocking it, I’d greatly appreciate the guidance.
Firewall software often has features to block addresses that are on some form of external blocklist. Common reasons might include known Tor exit nodes, for example.
The NTP Pool project only concerns itself with whether a provided pool server is a functioning NTP server. The project’s monitoring system (only) checks pool servers for reachability and time accuracy.
If your firewall is blocking something you should ask your firewall provider about that. IP addresses are only removed from the NTP Pool project if they don’t perform as an NTP server, or if they were submitted by someone who is not authorised to do so. Neither of those is likely to be the case in your situation, but if that were the case then the IP address would just be removed from the pool.
The term, “rogue NTP server” is not well defined. There isn’t a circumstance in which the NTP Pool project would object to an IP address, keep it in its database, but then inform some third party so that firewalls like yours could block it. If the project rejects an IP address then it isn’t served to users, so it follows that if your firewall is blocking an IP address then either you did that or your firewall did that for you - not the NTP Pool project.
As @grifferz indicated, the fact that it’s included in queries under pool.ntp.org means it is serving NTP and the time being served is in the ballpark (I think within 15ms, but it might be 75ms, certainly within 0.1s).
You can see this yourself with a query using ntpdate with -q or -d to query without setting the clock:
C:\Users\daveh\OneDrive\Documents>ntpdate -d -p 3 ntp.md
24 Jun 18:25:03 ntpdate[41164]: ntpdate 4.2.8p18@1.4062-o Jun 11 5:31:11.85 (UTC-00:00) 2025 (2)
host found : ntp.md
24 Jun 18:25:03 ntpdate[41164]: Raised to high priority class, realtime requires Increase Scheduling Priority privilege (enabled with secpol.msc).
Looking for host ntp.md and service ntp
2001:470:e114::123 reversed to ntp.md
transmit(2001:470:e114::123)
receive(2001:470:e114::123)
transmit(38.81.211.177)
receive(38.81.211.177)
transmit(2001:470:e114::123)
receive(2001:470:e114::123)
transmit(38.81.211.177)
receive(38.81.211.177)
transmit(2001:470:e114::123)
receive(2001:470:e114::123)
transmit(38.81.211.177)
receive(38.81.211.177)
server 2001:470:e114::123, port 123
stratum 1, precision -22, leap 00, trust 000
refid [GPPS], root delay 0.000000, root dispersion 0.001373
reference time: ec056bea.f8da5eda Tue, Jun 24 2025 18:24:42.972
originate timestamp: ec056c04.25ec475a Tue, Jun 24 2025 18:25:08.148
transmit timestamp: ec056c04.250fadf3 Tue, Jun 24 2025 18:25:08.144
filter delay: 0.03152 0.03130 0.03003 ----
---- ---- ---- ----
filter offset: +0.000928 +0.000742 +0.001086 ----
---- ---- ---- ----
delay 0.03003, dispersion 0.00020, offset +0.001086
server 38.81.211.177, port 123
stratum 1, precision -22, leap 00, trust 000
refid [GPPS], root delay 0.000000, root dispersion 0.001373
reference time: ec056bea.f8da5eda Tue, Jun 24 2025 18:24:42.972
originate timestamp: ec056c04.5aa43722 Tue, Jun 24 2025 18:25:08.354
transmit timestamp: ec056c04.59bf26f2 Tue, Jun 24 2025 18:25:08.350
filter delay: 0.03394 0.03630 0.03177 ----
---- ---- ---- ----
filter offset: +0.002609 +0.002921 +0.000382 ----
---- ---- ---- ----
delay 0.03177, dispersion 0.00172, offset +0.000382
24 Jun 18:25:08 ntpdate[41164]: adjust time server 2001:470:e114::123 offset +0.001086 sec
C:\Users\daveh\OneDrive\Documents>
I understand that my Ubiquiti UDM PRO Max’s default firewall settings are blocking the IP address, likely due to an external blocklist, and that this issue is unrelated to the NTP Pool Project. I also see that the NTP server in question is likely functioning correctly, as the pool’s monitoring system would have removed it otherwise.
My concern is that if my default firewall settings block this IP address, other users with similar setups might face the same issue, possibly without realizing it. This results in no time synchronization response for that IP, which could cause systems to issue additional DNS queries for another NTP server, increasing data traffic. If this affects multiple users, it could lead to a poorer NTP pool experience and unnecessary network overhead.
Could the NTP Pool Project consider investigating whether certain pool servers are commonly blocked by default firewall settings? This might help improve the overall reliability of the pool for users with similar configurations.
Yes, it’s very likely that this is the case. You haven’t let us know why your firewall is blocking this IP so I can only guess, but it is not uncommon for firewalls to offer features such as “block all known Tor exit nodes” while at the same time the NTP Pool project does not take a position that “pool volunteers must not run Tor exit nodes”.
People running firewalls are responsible for understanding what they have chosen to implement.
I can’t speak for anyone else but I think it’s unlikely that anyone here is going to spend time working out why the IP address of an otherwise functioning NTP server is blocked by one or another brand of firewall. Users of such firewalls may be more motivated.
Also if we did find out the reason, it’s also likely going to be the case that the reason is not going to be anything that we find disqualifying and the advice will be the same: the user should work out what their firewall is doing and decide if they agree with it.
If it is something you feel strongly about, you could find out what is going on and write about it so at least there will be some hits in a search engine for others to find. Maybe it could end up being documented on the pool’s web site. As I say my best guess is Tor exit node, but it could also be something like “IP addresses from a country I don’t like”.
Client systems getting an IP address they don’t want to use is not going to impose any noticeable extra DNS load. Each DNS query returns several addresses; clients will just use others.
Just an update: my UDM Pro Max is blocking an IP from the pool, and after checking on a website, it turns out the IP is on the DAN TOR blacklist. That’s likely the reason. I’m leaving it at that and won’t take any further action. Thanks for the input!