I have Airtel (ISP) Broadband at home. Same ISP is also my Mobile Network provider. I have DIR 615 router connected to Airtel Broadband, Windows 10 desktop and laptop.

When I am on Airtel Broadband both Windows 10 PCs fail to sync time with various Internet NTP Servers. It returns Time Out. I have tried over 10 – 12 NTP servers. However other devices like my Linux VM as well as DIR 615 router are able to sync time properly on same broadband with same NTP Servers. Yet when I switch to VPN on Windows 10 and bypass ISP, Windows 10 PC is successfully able to sync time with various NTP servers.

Also, when I use third-party applications like Nistime32bit.exe they sync time with NTP servers on same Windows 10 PC on Airtel Broadband successfully. I have tried on both TCP 13 as well as UDP 123 ports. Now when I am Airtel mobile hotspot, both Windows 10 PCs sync time properly without giving any Time Out error. It’s hard to believe that ISP is blocking outbound ports because Router & Linux VM sync correctly on same network and even third-party apps on Windows 10 PC. Yet Windows 10 PCs with Windows 10’s built-in process error out. It’s hard to believe that there’s problem with both Windows 10 OSes because they sync correctly on mobile hotspot. W32time service is running fine on both PCs.

I asked for help from ISP but they are not responsive.

Does anyone know what’s really happening here? What more can I try to troubleshoot and where the issue could be? I checked Event Viewer, it’s bunch of events but nothing meaningful found.

Firewall is completely OFF in Router as well as Windows 10. Same results if I bypass router and make a direct PPPoE connection from my PC to ISP.

enter image description here

Edit after seeing comments and answer.

I have tried several servers including a few located in my country but the behavior is consistent. Broadband -Failure, VPN – Success, Mobile Hotspot - Success. Router on Broadband – Success, Linux VM on Broadband – Success.

Thank you @user1686 for detailed answer. That was the missing link in the puzzle.

All ISPs in my country work and behave the same way. They all block incoming ports below 1024. I was under the impression that for NTP sync it’s client-to-server but was not aware about Symmetric 123 < -- > 123 of Windows so that even inbound 123 matters.

I have now tested that my ISP indeed blocks UDP 123 inbound by sending magic packets to remotely start my PC. When I send it to say UDP 4000 (Routed to UDP 9 in router), thru my Mobile Internet to Broadband Public IP it wakes-up, but on UDP 123 (Routed to UDP 9) it fails. I have also used a small utility called SimplePort Tester (PCWinTech.com) to recheck that indeed UDP 123 inbound is not accessible.

I tried time sync on my Windows XP VM assuming that it might be using older NTPv3 but it even failed to sync time on Broadband. So, looks like even XP back in those days was using 123 < -- > 123.

I will persuade my ISP to open inbound UDP 123 at least for sometime for testing but chances are very less that they will consider my request at all!

enter image description here

  • 1
    Perhaps more info can be found in the Event Viewer.
    – harrymc
    Commented Mar 12, 2021 at 11:47
  • Have you tried time.nist.gov? If you're not in the US, use the governmental NTP address for that country, as timeout errors usually occur because there's too much of a connection lag. If unable to fix the timeout, use your router's IP. (One potential cause could be ISP link saturation - are any network-intensive devices/services being used when trying to sync, such as gaming, streaming, etc.?)
    – JW0914
    Commented Mar 12, 2021 at 13:32

1 Answer 1


Most NTP and SNTP clients work in "Client/Server" mode. This is the same as other UDP clients – the computer sends an NTP query from an ephemeral port to the server's NTP port 123, gets a response back from port 123 to that ephemeral port. This is most likely how your Linux NTP client behaves.

Windows' built-in NTP client, however, uses "Symmetric" mode, in which it sends packets from local port 123 to the server's port 123. The responses, likewise, arrive from remote port 123 to local port 123.

(This symmetric port usage is somewhat unique to NTP, and is more commonly found in peer-to-peer situations when two NTP servers sync to each other. I'm not sure why Windows does this, but it might be due to the fact that Windows Server can act as a real NTP server, as part of AD DC functionality.)

But the problem with "Symmetric" mode is that to a network firewall, these inbound responses to your port 123 are completely indistinguishable1 from inbound requests to port 123.

Many ISPs deploy network-level firewalls to block certain "risky" protocols, e.g. those which are easy to abuse for DDoS amplification, and NTP is unfortunately one of them. So as a precaution, an ISP might block all UDP packets inbound to its customers' port 123, incorrectly believing that this only prevents the customers from running an NTP server.

Alternatively, the ISP might be doing this under the assumption that all customers have personal routers with NAT, and many routers actually reassign the local port of outbound packets – so even if a computer sends a packet 123→123, the router might translate it to 61473→123 and the problem will not occur. However, not all routers do that kind of remapping (this type of NAT often ends up interfering with games).


  • If your router lets you choose between "Cone NAT" and "Symmetric NAT", try switching to the latter and see if it helps (and no, the term actually has nothing to do with symmetric NTP at all).

  • Otherwise, you might need to continue using third-party NTP clients, which operate in Client mode and do not have this problem.

  • There is a Microsoft KB article about specifying which mode to use, but while it affects the mode bits in the NTP header, it does not actually make Windows to use a different source port. Unfortunate.

    (NTPv3 did specify that the source port must not be 123 in client mode, but NTPv4 no longer forbids this, so that might be why Windows happily uses 123→123 regardless of what mode flags are specified in the NTP header.)

1 A stateful firewall, like the one on your home router, can distinguish queries from responses by keeping track of previously seen outbound packets. But while stateful firewalls are common at smaller network boundaries, I suspect that they don't easily scale to "whole ISP" levels, as looking up state for each packet means reduced performance. So if the ISP operates a stateless firewall, the statement is still true – the two kinds of NTP packets become indistinguishable in symmetric mode.

  • It would be highly irregular for an ISP to block port 123 since it's well-known it's for NTP and doing so would create massive headaches for not only consumer accounts, but businesses as well. If an ISP was blocking 123, they'd ensure their customers were aware of it via a support page on their help site; however, I've never come across anyone stating their ISP blocks port 123 in the last decade. Possible, sure - likely, no.
    – JW0914
    Commented Mar 12, 2021 at 13:24
  • @JW0914: You completely missed the point of this post. They don't block "port 123". They block inbound packets to port 123. (If you look at e.g. a DNS packet you'll see that it doesn't just have "port 53", it has source port something-or-other and destination port 53, or the other way around. Thus firewalls can still allow inbound responses but not inbound queries.) Commented Mar 12, 2021 at 14:28
  • It's common for some ISPs to block certain kinds of traffic, but I've never come across an ISP in the last decade that does what you describe for NTP requests. I found your answer to be informative and what I'm inferring is no one can prove a negative - are you aware of any ISP that does this specifically to NTP traffic?
    – JW0914
    Commented Mar 12, 2021 at 14:36
  • 1
    I'm speaking from experience regarding the Windows NTP problem; our ISP had a decade-old firewall rule for "dst addr [our IP] && dst port 123" which was once supposed to block a mismanaged NTP server, but years later ended up blocking Windows clients as well. (They removed it.) I'm not actually aware of specific ISPs doing this for NTP on a permanent basis, but I wouldn't be the least bit surprised if some did, keeping in mind last year's ntpd security issue which allowed for some massive DDoS. (Similar to the "Open resolver" thing.) Commented Mar 12, 2021 at 14:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .