Problem with Intercept NTP client requests

[Magister]

For a long time now I have this option "Intercept NTP client requests" set to enabled, and all my devices basically are using the router as NTP server.

But, one of my new device, a TP-Link tapo C200 webcam, cannot update its date/time if this option is enabled. I have to disabled it for it to acquire right time.

How can I add a rule in the firewall/iptables for this particualr device to not have its port 123 be intercepted?

 

[Magister]

oh god iptables... I played with it 10 years ago and remember it is nightmarish, but I know I needed to dive in it again to fix my problem

So I checked in firewall.c how the rule is added, then googled a bit to find how to filter a particular MAC address for this rule not to apply, then how to use the right custom script to put new rule.

I created a /jffs/scripts/nat-start containing:

#!/bin/sh

# in case of, delete old generic rule that forward all NTP
iptables -t nat -D PREROUTING -i br0 -p udp -m udp --dport 123 -j REDIRECT --to-port 123

# basically the same rule except we filter TP-Link camera using non standard protocol on port 123
iptables -t nat -A PREROUTING -i br0 -p udp -m udp --dport 123 -j REDIRECT --to-port 123 -m mac ! --mac-source 34:60:F9:xx:xx:xx

It seems to work, it deletes the old rule and insert this new one.

Q to pro here, is this looking ok? Is this the right way to do it? Should I use br0 interface or another one?

 

[sluzza]

I'm not a pro, I'm afraid, but I'd be interested to see this working. I have a CCTV unit that I don't want to grant internet access but it needs access to an NTP server. I usually use Merlin's f/w as it allows NTP interception but the latest f/w from Asus has a couple of undocumented CVEs and some other security-type fixes so I'm on that instead at the mo'.

Running your script from the ssh prompt reports: "iptables: No chain/target/match by that name." Which version of the f/w are you running?

 

[ColinTaylor]

Running your script from the ssh prompt reports: "iptables: No chain/target/match by that name." Which version of the f/w are you running?

The first command will produce that error message because you're not using Merlin. The second command is fairly pointless in your case because you're not running an NTP server on your router (because you're not using Merlin).

 

[Magister]

I'm not a pro, I'm afraid, but I'd be interested to see this working. I have a CCTV unit that I don't want to grant internet access but it needs access to an NTP server. I usually use Merlin's f/w as it allows NTP interception but the latest f/w from Asus has a couple of undocumented CVEs and some other security-type fixes so I'm on that instead at the mo'.

Running your script from the ssh prompt reports: "iptables: No chain/target/match by that name." Which version of the f/w are you running?

Yeah the first command tries to remove a rule, if it does not exist in your setup you have this warning, it's normal.

 

[vlord]

For a long time now I have this option "Intercept NTP client requests" set to enabled, and all my devices basically are using the router as NTP server.

But, one of my new device, a TP-Link tapo C200 webcam, cannot update its date/time if this option is enabled. I have to disabled it for it to acquire right time.

How can I add a rule in the firewall/iptables for this particualr device to not have its port 123 be intercepted?

I had an issue a while ago with NTP where my router wouldn't update. I changed over to chrony and my ntp sync issues magically disappeared. Try switching and see if your devices will sync locally. Much easier than playing with iptables.

 

[Magister]

My issue seems to be that TPLink is using a non-standard or not-supported protocol on the port 123 to get its date/time, so I bypass the redirect

 

[vlord]

My issue seems to be that TPLink is using a non-standard or not-supported protocol on the port 123 to get its date/time, so I bypass the redirect

I have a TP Link lightbulb that attempts sync with an NTP server but have it redirected to my router's chrony server with no issues.

 

[Deleted member 27741]

Just what I was looking for Magister. Nice fix as I have the same issue with a Mikrotik hex!

Strange thing is- the hex ntp client is pointed at router.asus.com but only works without the redirect rule. Maybe the rule could be improved so it would work, but for now this bypass you have cooked up is just the thing.

 

[drinkingbird]

Just what I was looking for Magister. Nice fix as I have the same issue with a Mikrotik hex!

Strange thing is- the hex ntp client is pointed at router.asus.com but only works without the redirect rule. Maybe the rule could be improved so it would work, but for now this bypass you have cooked up is just the thing.

Why do you need your devices to use the router for NTP? Just let them all hit pool.ntp.org and be done with it. If anything the NTP proxy is resulting in worse accuracy, or worst case the same accuracy as going direct.

 

[Magister]

Why do you need your devices to use the router for NTP? Just let them all hit pool.ntp.org and be done with it. If anything the NTP proxy is resulting in worse accuracy, or worst case the same accuracy as going direct.

Windows do not use pool.ntp.org, some devices you have no control on use different NTP servers. I had problem with distcc for instance when using multiple PC to compile files, with "time in the future" problem.

 

[drinkingbird]

Windows do not use pool.ntp.org, some devices you have no control on use different NTP servers. I had problem with distcc for instance when using multiple PC to compile files, with "time in the future" problem.

I'd have pretty big concerns with any device that can't manage to use an accurate NTP server...

You can set windows to use what you want but I've never had any issues with the default MS one either.

But the poster I was replying to was specifically pointing his device at the router, so not even using NTP intercept but just proxying it, didn't see any point in that.

 

[glens]

The point is to relieve the pressure on the NTP infrastructure. Though it's less important for this protocol, it's the same reason one should run a local caching nameserver, especially if having more than one local device performing queries.

 

[Deleted member 27741]

Why do you need your devices to use the router for NTP? Just let them all hit pool.ntp.org and be done with it. If anything the NTP proxy is resulting in worse accuracy, or worst case the same accuracy as going direct.

Thanks for your input.

I am using the Mikrotik HEX device that is behind my AX86U as a vpn server. For security on said vpn server I have only the necessary ports open through the Mikrotik HEX firewall. On the Mikrotik HEX, the NTP port 123 is only open to local traffic. Is that completely necessary? No, however for a vpn server I prefer to have its firewall pretty locked down. Personal preference, I suppose. YMMV.

 

[drinkingbird]

The point is to relieve the pressure on the NTP infrastructure. Though it's less important for this protocol, it's the same reason one should run a local caching nameserver, especially if having more than one local device performing queries.

I disagree, when accuracy is at stake you want to have as few hops as necessary. Pool.ntp.org has dozens of servers and an NTP query is tiny. I would not trust the asus to have the necessary accuracy for true NTP anyway (depending on the accuracy you need anyway).

 

[drinkingbird]

Thanks for your input.

I am using the Mikrotik HEX device that is behind my AX86U as a vpn server. For security on said vpn server I have only the necessary ports open through the Mikrotik HEX firewall. On the Mikrotik HEX, the NTP port 123 is only open to local traffic. Is that completely necessary? No, however for a vpn server I prefer to have its firewall pretty locked down. Personal preference, I suppose. YMMV.

You have the port open if it is functioning... whether it queries the Asus or a server beyond that, basically the same thing from the Hex's perspective, port 123 outbound. You can still use the hex as a proxy if you want but then using the Asus as a second proxy doesn't make any sense.

 

[Deleted member 27741]

You have the port open if it is functioning... whether it queries the Asus or a server beyond that, basically the same thing from the Hex's perspective, port 123 outbound. You can still use the hex as a proxy if you want but then using the Asus as a second proxy doesn't make any sense.

Thanks for your input. Not making sense is my middle name.

 

[glens]

I disagree, when accuracy is at stake you want to have as few hops as necessary. Pool.ntp.org has dozens of servers and an NTP query is tiny. I would not trust the asus to have the necessary accuracy for true NTP anyway (depending on the accuracy you need anyway).

Absolute accuracy isn't always absolutely necessary so much as having all ones' local clients in very good sync, most "times."

I confess I'm quite likely behind the times with my understanding, but a quick duckduckgo turned up https://labs.ripe.net/author/christer-weinigel/best-practices-for-connecting-to-ntp-servers/ from now a couple years ago, and a quick scan through it seems to only bolster what I've been thinking. It's a good read with at least a couple considerations for everyone here.

 

[sfx2000]

How can I add a rule in the firewall/iptables for this particualr device to not have its port 123 be intercepted?

Kind of necroposting - but this rule generally works...

# Redirect NTP requests to go through router
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 123 -j DNAT --to 192.168.1.1
iptables -t nat -A PREROUTING -i br-guest -p udp --dport 123 -j DNAT --to 192.168.1.1

 

[drinkingbird]

Absolute accuracy isn't always absolutely necessary so much as having all ones' local clients in very good sync, most "times."

I confess I'm quite likely behind the times with my understanding, but a quick duckduckgo turned up https://labs.ripe.net/author/christer-weinigel/best-practices-for-connecting-to-ntp-servers/ from now a couple years ago, and a quick scan through it seems to only bolster what I've been thinking. It's a good read with at least a couple considerations for everyone here.

The concern the author expresses is not with overloading public NTP but that somehow it will result in inaccuracy since you can't ensure they will all use the same server. That assumes that NTP is completely broken, or that the NTP provider you're using is incompetent. The protocol takes into account any offsets and corrects itself, that's the entire point of it. However when you get more and more "hops" in the path each one is doing a correction and you start to get more and more "creep".

If you want to have it synched to your Asus, so be it, personally I'd rather something much more reliable be handling it (this particular bug that keeps popping up is just an example of that unreliability). Who wants to find out when they really need to find something in their log time stamped correctly, that their timestamps are not accurate? You probably wouldn't notice otherwise, at least not until it got really bad.