Does RouterOS block NTP traffic by default?

Level of experience: advanced home user. I’m a computer programmer, but not a network engineer, so I have only a rudimentary understanding of the technology involved. But I can understand these topics quickly if I know what to look for.

Problem: for years now none of my home PCs (Windows boxes all) have been able to use internet time synchronization. Which is a shame, the clocks do drift significantly. In fact, this was even BEFORE I bought a Microtik router, so my ISP is actually a prime suspect, but I haven’t been able to pin it to them yet…

Lately I got pissed off by this again and started investigating more. I downloaded some sort of tool for debugging NTP and noticed something odd:

When the w32time service is running, it’s allocating port 123 and the separate tool cannot use it. So the tool instead uses another random port and THAT WORKS. However when I stop the service, port 123 becomes available, the tool takes it, and then the tool stops working too.

So obviously, something is blocking port 123, but what?

My first thought was my ISP, however I’m behind a NAT, so the port number visible to my ISP will probably not be 123. That leaves either my own PC or the router. I’ve already tried disabling the firewall on my PC (I only have the Windows built in one), but no luck. So that leaves my hAP ac2 as the primary suspect. Unfortunately I don’t know it well enough to find such a setting, if it’s there at all.

So - does anyone here know if RouterOS is blocking traffic on port 123?

No, RouterOS does not block NTP traffic by default.

Where you go wrong: “however I’m behind a NAT, so the port number visible to my ISP will probably not be 123”.
That is not the case, at least not for a single NTP session. RouterOS will try to keep the port number unchanged. Only when it cannot do that because two internal systems are doing NTP to the same external server, it will change the portnumber.

My guess is that your ISP blocks incoming traffic towards port 123 because it is sometimes used for DDoS amplification, and you are now a victim of that.
However, don’t despair. Your MikroTik router can translate the port number when that is required.
You can insert another NAT rule before the generic one you are using for all your traffic, which specifies protocol udp and source port 123, and instead of “masquerade” you can use “src-nat” and select another source port number (e.g. 12300).

@Vilx, if your WAN router can be configured as a ntp server, then do so, and in your LAN give all your machines just the IP of the router. Works here.
And: I would recommend to use the ntp-servers of your ISP because it’s nearer to you (ie. less latency, ie. fast), and you can trust your ISP more than other providers, IMO.

In case your WAN router does not have ntp-server capability, then again just use the ntp-server(s) of your ISP → just ask them for the addresses of their ntp servers that their clients can use.

You can also set-up your own ntp-server for your LAN on any server machine: just install the ntp server service on a machine in your LAN and configure it, and all the other machines in LAN shall just use the IP of that local ntp-server. But as said, it would be better if you can use the router as ntp-server for your LAN.

Ie. there is an ntp-server (or multiples), and there are ntp-clients… You normally need just 1 ntp server to serve your whole LAN.

So, to summarize:
First check whether your WAN router gets the correct time (see it’s log entries for example). Then check whether it has ntp-server service. If yes, then configure it and use the IP of the router in all ntp-clients. Normally you don’t need to do anything in the firewall rules, unless you have a very strict firewall policy in your LAN.

And regarding port 123 on your machine: if you have a ntp-server running on that machine, then it of course will bind to port 123 as this is the port to serve other ntp-clients.

I believe both of the previous responses was either backwards or missed the mark, so I am going to give my 2 cents.

When you are connecting to a time server, you do so on port 123. This is no different from http on port 80 and https on port 443. The return port is what will be random. Your device will use one random port, your router will stamp its own return port. if there is NAT on modem it will stamp its return port, but the to port stays the same.

Your assumption of your ISP blocking your connection to port 123 is most likely correct. To test this you could install a free VPN service to device and see it works. Or search for outgoing port tester, there are some that you use like telnet to see if can connect to that port.

@2frogs, why should an ISP block outgoing port 123 ? Have you ever seen an ISP block outgoing port 80 or 443 ? :slight_smile:
These outgoing ports are essential ports, so very unlikely that any ISP blocks them.

I didn’t say they should! It could be done in a poor attempt to redirect to their own server. Or a Mom/Pop shop that just doesn’t know any better.

The fact the OP stated this was ongoing from before his Mikrotik router implies to me it is the ISP.

Sorry, I neither get nor understand your argumentation. What should whom do?

Auto correct victim… or poor typing skills…

“ I didn’t say they should.”

No Mikrotik does not block NTP by default
yes Mikrotik seems to want to use 123 as Src. Port. Interesting…

to check Mikrotik has send NTP packat from your PC, add a filrewall rule to show what’s going on: in terminal add:

/ip firewall filter add action=accept chain=forward dst-port=123 log=yes protocol=udp

watch the log to see Mikrotik has sent NTP packet to the NTP server. This is the conversation going through my Mikrotik when I press Sync Now on Windows 10 Date and Time settings:

13:49:33 firewall,info forward: in:bridge out:lte1, src-mac 04:18:d6:xx:xx:xx, proto UDP, 192.168.90.98:123->51.105.208.173:123, len 76
13:49:33 firewall,info forward: in:lte1 out:bridge, src-mac ee:6c:38:fe:21:c1, proto UDP, 51.105.208.173:123->192.168.90.98:123, NAT 51.105.208.173:123->(192.168.42.11:123->192.168.90.98:123), len 76
13:49:35 firewall,info forward: in:bridge out:lte1, src-mac 04:18:d6:xx:xx:xx, proto UDP, 192.168.90.98:123->51.105.208.173:123, NAT (192.168.90.98:123->192.168.42.11:123)->51.105.208.173:123, len 76
13:49:35 firewall,info forward: in:lte1 out:bridge, src-mac ee:6c:38:fe:21:c1, proto UDP, 51.105.208.173:123->192.168.90.98:123, NAT 51.105.208.173:123->(192.168.42.11:123->192.168.90.98:123), len 76

This is the packet coming from the ntp server as an ntp server operates at port 123.
ntp clients use other (temporary) ports as they run just for a short amount of time since they are no servers.

@mutluit
192.168.90.98:123 is my PC, which would be an NTP client
also I tested setup the NTP client within Mikrotik, log shows the Mikrotik also use Src Port 123 as well.

Normally an ntp-client should not use the reserved source port 123 as it is for the ntp-server.
Are you sure it is the ntp-client on the MikroTik? Maybe you should reboot that device, and verify again. A screenshot would be helpful too.

And: to which ntp-server do these ntp-clients connect?
Man, you need an ntp-server, either in your LAN or somewhere in the WAN, so that your ntp-clients can connect to it. Is that not obvious?

yes I was expecting the Src port to be a random port, just like when you use web service at 80 or 443, the traffic would be leaving your private IP from port xxxx.
windows 10 PC is connecting to time.windows.com

I have setup my mikroitk as :

/system ntp client
set enabled=yes server-dns-names=2.uk.pool.ntp.org

and if you add a firewall filter for dst port 123, on the output chain, you will see which port the traffic is leaving your router.

this is only setup to test, normally I’d just use

/ip cloud set update-time=yes

which uses encrypted packets to cloud.mikrotik.com or cloud2.mikrotik.com using UDP/15252 port,
it is described here: https://wiki.mikrotik.com/wiki/Manual:IP/Cloud#Update_time

@solar77 we have our own time server in our LAN. Here it says this:

[admin2@CRS326] > /system ntp client print
enabled: yes
mode: unicast
servers: 192.168.254.254
freq-drift: 5.845 PPM
status: synchronized
synced-server: 192.168.254.254
synced-stratum: 2
system-offset: 1.45 ms

[admin2@CRS326] > /ip cloud print
ddns-enabled: no
ddns-update-interval: none
update-time: no

>

Vilx, most likely that’s your ISP who blocks the NTP traffic.

I had similar issue with my ISP. They were blocking NTP for some reason and also dropping a PPPoE session every night. I contacted their support team and both issues have been fixed. Don’t ask me why there were doing this, maybe for the purpose of preventing possible DDoS attacks, as @pe1chl mentioned in the very first reply.

RouterOS will try to keep the port number unchanged.

Ahh, that explains it! Yes, then I think it’s it’s quite likely that my ISP is to blame. They also block other things like any outbound TCP connections TO port 25. I guess all this makes sense to prevent malicious activity, but it is annoying.

You can insert another NAT rule before the generic one you are using for all your traffic, which specifies protocol udp and source port 123, and instead of “masquerade” you can use “src-nat” and select another source port number (e.g. 12300).

This seems like the right direction, but I’m concerned about one thing. I have multiple devices at my home (4 PCs, 3 cell phones). If I add the

src-nat

rule, does that mean that my router will route them ALL through the same destination port? Won’t that end up confusing everything?

Also - where in Winbox do I configure that? I cannot find the place.

You can specify a range of ports to be used, e.g. 12300-12399, and it can select one from that.
This is configured in IP->Firewall->NAT.
You will already find a rule there. Copy that and set the UDP protocol and dest. port 123, and change it to src-nat with the proper port.
You will also need to insert the external IP address in there, hopefully it is static.
(with masquerade instead of src-nat you don’t need to specify that, but it cannot do the port translation)
After adding the new rule, move it above the existing one.

TCP/25 is normal to block due to email spam from various old viruses and wrongly configured email server.
UDP/123 is not normal to block.
Why in the world wold they do that? Call them and ask.

It’s called “ntp amplification attack”. The NTP protocol is old and insecure, and it can be abused to stage DDoS attacks by tricking innocent machines on the net to spam a single target with NTP responses. Blocking UDP port 123 is a crude but effective way to stop that.

In the original NTP implementation there is (besides the normal “gimme the time” request) a debugging request that asks the timeserver for the last 1000 or so clients it has seen, returning their IP address, number of requests, average time between requests, etc.
The reply is obviously quite large, compared to the request. And as it is UDP, you can often fake the source address of the request (especially when you are at a lousy ISP!).

So the bad guys sent requests to NTP servers, with source address of some website they want to take down, destination address the timeserver, and request code is that “send me the list of clients”. The NTP server would then send that data to the website and it would receive a lot of incoming traffic (because they would repeat this action quickly and with many different timeservers).

As so often on the internet, this implementation had been on the internet for a decade or so and it never caused problems, until the bad guys found this and started exploiting it.
Then suddenly the task was upon every time server admin to go into their configuration file and turn off the availability of this command.

As ISPs get quite overburdened by complaints from external parties (victims of the attack) that one of their customers is running a badly configured NTP server, and it is often quite difficult to contact a responsible person and have it fixed immediately, they often have chosen to block NTP traffic towards customers.
Customers could still make NTP requests when they make sure the port number is different from 123 (or they would not receive the reply), but they no longer can run a server.

Unfortunately as Vlix already noticed, a lot of software always uses port 123 as the source port even when operating solely as a client, and you need to translate the port in the router.