Configure a Local NTP Server on MikroTik RouterOS
Synchronize RouterOS across multiple sources, distribute time over the LAN via DHCP, protect UDP 123, and optionally redirect reluctant clients.
An exact time is not a cosmetic detail. Firewall logs, TLS certificates, authentication, scheduled tasks, backups, and incident correlation all rely on consistent clocks. When every camera, NAS, server, and connected device queries its own service on the Internet, the administrator loses both visibility and control.
RouterOS 7 can solve this problem by playing two roles: an NTP client towards multiple external sources, and then a unicast NTP server for the local network. Clients then use the MikroTik's address as a reference. A redirect rule can also intercept UDP 123 requests sent outwards, but this measure must remain optional and controlled.
Architecture and limits
The recommended flow is simple: multiple NTP sources feed RouterOS, RouterOS advertises its address via DHCP, and then clients query it in unicast. The firewall allows UDP 123 from the LAN and rejects requests arriving from the WAN.
The examples use:
- the network
192.168.88.0/24; - the router
192.168.88.1; - the interface lists
LANandWAN; - the timezone
Europe/Brussels; - four names from the Belgian NTP pool.
Adapt the addresses, the WAN interface, and the timezone. NTP carries time in UTC; the timezone only changes the router's local display and the timestamp presented by its tools.
1. Back up and check prerequisites
Work from the LAN and enable Safe Mode with Ctrl+X. Keep an export and a binary backup before modifying the firewall or DHCP.
/export file=avant-ntp
/system backup save name=avant-ntp
/system resource print
/system clock print
/system ntp client print
/system ntp client servers print detail
/system ntp server print
/ip dhcp-server network print detailNTP server names require functional DNS resolution. Also check IP access.
:put [:resolve 0.be.pool.ntp.org]
/ping 1.1.1.1 count=42. Set the timezone
/system clock
set time-zone-name=Europe/Brussels
/system clock printThe RouterOS timezone database automatically applies daylight saving time according to the timezone rules. Avoid a fixed UTC offset: it would become false at the seasonal change.
3. Choose multiple NTP sources
The RFC 8633 best practices guide recommends at least four independent sources when reliable time is important. Four sources allow keeping three opinions if one becomes unavailable or inconsistent.
For a network located in Belgium, the NTP Pool Project publishes 0.be.pool.ntp.org to 3.be.pool.ntp.org. Names are preferable to hardcoded addresses: the pool can rotate the servers returned by DNS. For critical infrastructure, use contractually operated sources, internal clocks, or a dedicated architecture instead.
/system ntp client
set enabled=yes mode=unicast
/system ntp client servers
add address=0.be.pool.ntp.org comment="NTP Pool BE 0"
add address=1.be.pool.ntp.org comment="NTP Pool BE 1"
add address=2.be.pool.ntp.org comment="NTP Pool BE 2"
add address=3.be.pool.ntp.org comment="NTP Pool BE 3"The default values min-poll=6, max-poll=10, and iburst=yes are generally suitable. Do not aggressively reduce the intervals: this does not make the clock magically more accurate and increases the load on services provided largely by volunteers.
If the WAN also receives NTP servers via DHCP, they may appear as dynamic entries. For a fully controlled selection, disable their import on the relevant DHCP client after identifying its interface.
/ip dhcp-client print detail
/ip dhcp-client
set [find where interface="ether1"] use-peer-ntp=noDo not run this second command if the WAN does not use DHCP or if the interface is not named ether1.
4. Verify that RouterOS is actually synchronized
/system ntp client print
/system ntp client servers print detail
/system ntp monitor-peersWait for the synchronized state. Also check synced-server, synced-stratum, and system-offset. Peers must show plausible delays and offsets. Successful DNS resolution does not prove that UDP 123 exchanges are actually passing.
5. Enable the unicast NTP server
For clients explicitly configured with the router's address, simply enabling the server is enough. Broadcast, multicast, and manycast modes are not necessary in this scenario and add traffic as well as an unnecessary diagnostic surface.
/system ntp server
set enabled=yes broadcast=no multicast=no manycast=no \
use-local-clock=no
/system ntp server printuse-local-clock=no prevents the router from presenting its internal oscillator as a valid reference when the upstream disappears. The MikroTik documentation reminds us that this clock depends notably on temperature, power management, and hardware: it does not constitute a source of precision.
6. Allow the LAN and close the WAN
The service listens on UDP 123. Add an authorization for trusted networks before the final reject in the input chain. A standard RouterOS firewall already blocks new connections from the WAN, but explicit rules make the intention verifiable.
/ip firewall filter
add chain=input action=accept in-interface-list=LAN \
protocol=udp dst-port=123 \
comment="NTP: allow LAN clients"
add chain=input action=drop in-interface-list=WAN \
protocol=udp dst-port=123 \
comment="NTP: deny WAN requests"Check the order with /ip firewall filter print. The LAN authorization must precede a general LAN reject, and the WAN rule must not replace established protections without an audit. An unnecessarily exposed NTP server can provide information and, depending on its implementation, participate in amplification abuses.
7. Advertise the router with DHCP option 42
RouterOS has an ntp-server field in each DHCP network. It corresponds to option 42 and accepts up to two addresses.
/ip dhcp-server network
set [find where address="192.168.88.0/24"] \
ntp-server=192.168.88.1
/ip dhcp-server network print detail \
where address="192.168.88.0/24"Clients must renew their lease or reconnect to the network. However, DHCP does not enforce the use of option 42: the server normally transmits it only if the client requests it, and some systems keep their own time policy. Workstations that are members of a domain, for example, must respect the time hierarchy defined by that domain.
8. Redirecting UDP 123: an option, not a reflex
An embedded device may ignore DHCP and query a hardcoded NTP address. RouterOS can redirect UDP 123 requests destined for a non-local address to its own service.
/ip firewall nat
add chain=dstnat action=redirect to-ports=123 \
in-interface-list=LAN protocol=udp dst-port=123 \
dst-address-type=!local \
comment="NTP: redirect LAN to RouterOS"Place this rule before a more general dstnat rule that would already intercept the packet. The dst-address-type=!local test avoids intercepting a request already addressed to the router.
Redirection has four important limits:
- it does not fix a defective client emitting thousands of requests: it shifts its load to the MikroTik;
- it hides the real identity of the source from the client and must be documented;
- it can break an authenticated NTP policy or a server that must reach a precise reference;
- it does not replace the configuration of manageable devices.
Create an exclusion list for domain controllers, NTS servers, GPS/PTP equipment, or laboratories that must reach a determined source, then add src-address-list=!ntp-bypass to the rule.
/ip firewall address-list
add list=ntp-bypass address=192.168.88.10 \
comment="Standalone time server"
/ip firewall nat
set [find where comment="NTP: redirect LAN to RouterOS"] \
src-address-list=!ntp-bypass9. Test from multiple systems
First check the RouterOS counters.
/ip firewall filter print stats where comment~"NTP:"
/ip firewall nat print stats where comment~"NTP:"
/ip firewall connection print where protocol=udp dst-port=123
/log print where topics~"ntp"Then query the router from the clients.
# Linux avec chrony
chronyc sources -v
chronyc tracking
# Windows
w32tm /stripchart /computer:192.168.88.1 /dataonly /samples:5
# macOS
sntp -d 192.168.88.1Linux commands show the source actually selected by the local service. Under Windows and macOS, the spot test confirms that the MikroTik responds; it does not prove that the system has changed its permanent source. Then check the platform's own time service configuration.
Security and precision
Classic NTP is not encrypted and, without a shared key, does not cryptographically authenticate the source. Centralizing clients reduces direct outbound traffic and facilitates observation, but does not protect the path between RouterOS and its sources against an on-path adversary.
RouterOS documents the use of NTP symmetric keys. They only work if the upstream server and the client share a consistently configured key. For a high integrity requirement, consider an internal server supporting Network Time Security, a properly secured GNSS reference, or a contractual time service. NTS is defined by RFC 8915 and should not be confused with simple UDP redirection.
Troubleshooting
| Symptom | Probable cause | Check |
|---|---|---|
RouterOS client in waiting | DNS, route, or UDP 123 blocked | Resolve FQDNs, check peers and the outbound firewall |
| The router responds with an invalid time | Upstream lost or use-local-clock=yes | Check status, stratum, and disable the local clock |
| Clients do not see option 42 | Old lease or option not requested | Renew the lease and inspect the client's NTP policy |
| NAT counter stays at zero | Client already configured on the router or misplaced rule | Test an external destination and check the dstnat order |
| The MikroTik receives too many packets | Defective connected device or loop | Identify the source address, isolate the client, and fix its firmware |
| An application rejects the time after redirect | Authentication or strict destination | Add the equipment to ntp-bypass |
| NTP responds from the Internet | input WAN rule too permissive | Test from the outside and check reject counters |
Rollback
First remove the redirection, then the DHCP advertisement and the service. Only delete the sources if they were created exclusively for this project.
/ip firewall nat remove \
[find where comment="NTP: redirect LAN to RouterOS"]
/ip firewall filter remove [find where comment~"NTP:"]
/ip firewall address-list remove [find where list="ntp-bypass"]
/ip dhcp-server network set \
[find where address="192.168.88.0/24"] ntp-server=""
/system ntp server set enabled=no
/system ntp client servers remove [find where comment~"NTP Pool BE"]If the router's NTP client existed before this procedure, leave it active. The router also needs a correct clock for its logs, certificates, and scheduled tasks.
Conclusion
A proper deployment does not consist of enabling all NTP modes. RouterOS synchronizes in unicast on multiple sources, then serves the LAN in unicast, advertises its address with DHCP option 42, and rejects requests from the WAN. This architecture is simple, measurable, and easy to document.
Transparent redirection can contain devices that ignore the network policy, but it must be monitored and accompanied by exceptions. The goal remains a consistent and traceable time, not just an increasing NAT counter.
Technical references
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.