Can all devices realistically be forced to use a specific NTP server with OpenWRT?

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi everyone,

I’ve been considering the idea of centralizing NTP traffic in my home network by forcing all devices to use an internal NTP server. I’ve already created a NAT rule on my OpenWRT router to redirect all UDP port 123 traffic to the internal server. However, this made me wonder about the practical implications of such a setup:

Questions

  1. Can all devices truly be forced to use the internal NTP server?
  • While NAT redirection works for most devices, I’ve noticed that some (e.g., Windows PCs) seem to bypass this and still query their preferred NTP servers unless manually configured. Is there any way these devices could still get through, or does the NAT rule effectively block them from using external servers?
  1. What happens if a device’s NTP request fails due to redirection?
  • If a device is hardcoded to use a specific NTP server and cannot successfully sync time via the redirected internal server, does this mean the device won’t sync its time at all? Or would it eventually retry with another server?

Practicality

I’m not looking for ways to hard-code every device to use the internal server but rather exploring whether this approach is even practical. It seems like some devices might either bypass the rule or fail to sync time entirely.

Has anyone here successfully implemented a similar setup without running into such issues? Would it be better to just accept that some devices will use external NTP servers?

Looking forward to your input!

2

You can do the following:

  1. Enable the NTP server on OpenWrt
  2. Set DHCP option 42 (NTP server advertisement) to point to the OpenWrt server address.
  3. Configure your firewall to hijack NTP and redirect it to the OpenWrt server. This will be essentially the same as the method to do DNS hijacking, just with port 123 instead of 53. This will prevent any NTP requests reaching the wan (for devices that don't listen to DHCP option 42) and instead will redirect it to your server.

https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns

3 Likes
3

No idea what you are talking about, show your configuration, especially around "nat rule" whatever that means and fails to redirect traffic.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
4

I'm very curious about how you are detecting this? If the OpenWrt firewall rule is redirecting all UDP port 123 traffic to itself properly, there's no way Windows can bypass that. Is it using a different port? That would be very, very weird, but with Windows???

3 Likes
5

Thank you all for your responses! I’d like to clarify my original idea, as the discussion has mostly focused on technical implementation, such as NAT rules and firewall configurations.

The main purpose of my post was more about pondering how different devices behave when their NTP requests are redirected to my own server (e.g., the Finnish Mikes NTP server) at the network level.

My key questions are:

  1. How likely is it that some devices, like iOS devices, verify the authenticity of the response (e.g., ensuring it comes specifically from time.apple.com)?

  2. If a device doesn’t receive a response from its hardcoded NTP server, could this cause issues with time synchronization, such as failures in timers or other functions?

  3. I am particularly interested in IoT devices – is it critical for these devices that NTP responses come specifically from the server they are trying to contact?

6
  1. very unlikely
  2. timers are local hardware elements
  3. they usually set clock from one ntp response, if that is poisoned... and so on. If they run OpenWRT or any linux you can use consensus time from multiple servers.
7

First, there are ways a client can account for wrong or delayed responses. That's not directly related to your question, but it is related to potentially tinkering with NTP responses, relying on a response and providing a custom NTP server.

Example: Pick not one but a couple of time servers. Ping them all to assume individual latencies. Ask them all for the time. Subtract the individual latency values. Ignore outliers that stick out the most. Take the average of the rest. This should provide a decently exact time.

Second, there are ways to protect from tinkering. Time servers can basically provide cryptographic signatures to their responses to allow clients to validate a certain response is unaltered.

If a vendor of any device wants to really make sure time information is controlled by himself, he would provide a custom server. If that vendor needed decently accurate time information, he would provide not one but a couple of servers. Not sure why a vendor would want that, though.

You, as a customer of said vendor, can, of course, redirect NTP requests to your own NTP server to prevent your devices from using the time information the vendor of your device provides.
The worst case would be that those devices detect your tinkering and stop working entirely, or even instantly cry for security staff because the vendor thinks time is important. I'd assume that's a reasonable scenario if we're talking about industrial security cameras, where alerting intrusion might depend on facility opening hours.
That's the worst case, of course. If we're talking about a camera taking hourly pictures of your lawn, where having time being off by a couple of seconds isn't a big deal, the $30 camera you put up might not do any of this, might ask one NTP server once a day, might not check for cryptographic signatures at all and might tolerate NTP not respond at all just fine.

How likely is it for your devices to check signatures and potentially act on wrong or missing signatures? Depends on the device, I guess.

There's only one way to find out: Set up a controlled lab environment where you can check each one of your IoT devices to see how they behave on different stages of NTP direction, tinkering and blocking.

If you need a project to kill some boring time, go for it. And feel free to write about your findings. But I'd personally not do any of this. I have no reason to believe a vendor I purchased a device from has bad intentions when it comes to NTP. And if I had, I'd either let it slip or dump that device.

2 Likes
8 
config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'redirect_NTP_LAN'
        list proto 'udp'
        option src 'lan'
        option src_dport '123'
        option dest_ip '192.168.1.1'

Of cource, you must enable NTP Server on the OpenWrt.

1 Like
9 
config redirect
-        option dest 'lan'
        option target 'DNAT'
        option name 'redirect_NTP_LAN'
        list proto 'udp'
        option src 'lan'
+       option family 'any'
        option src_dport '123'
-        option dest_ip '192.168.1.1'
1 Like