I have a VLAN for IoT devices that doesn't allow internet access.
It seems that the time on some IoT devices has drifted and therefore lights come on and off at the wrong time.
Presumably this is because they cannot reach a time server.
If I configure OpenWrt to serve time and DHCP Option 42, will the clients get time from OpenWrt? Does it depend whether the IoT devices have hard-coded NTP servers? Is NTP discoverable?
Chances are clients will ignore most of the DHCP options
You can intercept and redirect ntp traffic exactly like DNS
This is a long shot, but I experience it on some home-made ESP8266 thermometers I built about 10 years ago; if your IoT devices are similarly old, it might apply. The symptom on my devices is similar, they simply lose time lock and drift off into space.
From my notes:
I remedy this by making sure that the time server A record that the device is seeking is always in the router's dnsmasq cache by running a dig in a cron job on the router:
59 * * * * /usr/bin/dig -p 53 A time.nist.gov
Note also that the above 1-hour job interval requires ttl on the cache be set to a an hour:
$ cat /etc/config/dhcp
...
config dnsmasq
option min_cache_ttl '3600'
...
(I believe this will be fixed in the upcoming dnsmasq 2.91, we're still on 2.90 in all recent OpenWrt versions.)
Hi again lleachii Solution Institution 
Believe it or not, I did a rudimentary search before asking my question.
I was unaware of that option family 'any' directive. Will read up on that.
With config redirect, must there be a stanza for each subnet/VLAN?
I read elsewhere that it's not possible to use a src wildcard which is a shame.
Is the word redirect in option redirect user-defined? i.e. could I have option lan-redirect, option IoT-redirect etc.?
Does this proposed solution trap all NTP requests and redirect them, even if the destination NTP server is hard-coded in the IoT device?
I shall read up on DNS hijacking as it seems it is quite a popular topic and there are therefore more examples whcih can be applied to NTP as well.
Since you're redirecting to an IPv4 address, I'm not sure why you mentioned that. To be clear, you cannot redirect IPv4 to IPv6.
You could use SRC zone any - there are other options.
Interesting.
Yes.
(BTW, you don't have to make multiple posts to reply to everyone, we can all see.)
I'm a little confused. It appears your solution is to cache the IP addresss for time.nist.gov in dnsmasq so it can be given to your ESP devices? This is so they can then get time from time.nist.gov via its IP address, rather than needing DNS?
I want to make my devices get time from a different place, i.e. OpenWrt.
Perhaps I could redirect requsts to time.nist.gov to the IP address of OpenWrt which is running an NTP daemon.
@lleachii
Sorry, I try to make things clear when I'm replying as sometimes threads get confusing 
(maybe nested replies would be clearer, however I do really like this forum)
src 'any' would be good, I can't remember where I saw that you couldn't use a wildcard 
I mentioned that because brada4 had demonstrated it in the post you linked to above. brada4 showed that you could use option family 'any' instead of option dest and option dest_ip (in that example).
The line is actually:
option src '*'
In the DNS Hijacking guide, it says to configure the firewall Source zone: lan. I tried following the guide in Luci and it is not possilbe to group select all internal interfaces to achieve src *. Would I be able to manually change that in /etc/config/firewall after using Luci to build the rule as per the guide? Or can I use a comma seperated list of interfaces?
Also in that guide, it explains how to redirect the hijacked DNS queries to another server, explaining that those DNS servers would have to be in a different subnet to avoid masquerading. I don't fully understand that 
It's not a problem to have them in a different subnet, I would just like to understand the implication if they weren't.
Let's say I have OpenWrt on 192.168.1.1 and 2 pi-holes on 192.168.1.2 and 192.168.1.3.
I intercept all DNS requests on OpenWrt and redirect them to the pi-holes, where is the masquerading problem?
Continuing with the example devices above, I have a VPN gateway on OpenWrt which has a DNS server at the other end of the tunnel. I have configured OpenWrt to forward all DNS requests through the tunnel.
I have configured both pi-holes to use OpenWrt as their upstream DNS so that all DNS requests go through the pi-holes before the tunnel to remove ads etc.
If I now try and hijack the DNS requests on OpenWrt and send them to the pi-holes, I will end up with a loop won't I?
Would there be any way to exclude the pi-holes from the DNS hijacking?
You need rule per interface.
Is that contradicting lleachii then?
Place a file in /etc/nftables.d/whatever.nft
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
iif $iot_devices meta l4proto udp ct original proto-dst 123 counter redirect to :123
}
Check fw4 print for variable names and fw4 check to validate your typing.
My current chain dstnat is
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
iifname { "br-lan.1", "br-wifi", "br-lan.99" } jump dstnat_lan comment "!fw4: Handle lan IPv4/IPv6 dstnat traffic"
iifname { "pppoe-wan", "wan" } jump dstnat_wan comment "!fw4: Handle wanIPv4/IPv6 dstnat traffic"
}
so, provided my IoT VLAN is called br-lan.4, I could insert
iifname { "br-lan.4" } meta 14proto udp ct original proto-dst 123 counter redirect to :123
and activate busybox-ntpd with enable_server?
My bad, I was incorrect. It does need to be per interface. I didn't reference my rules before replying.
So is the word redirect in config redirect arbitrary?
If it is more than few similar rules it is more efficient to make a single one.
fw4 print will show variables available in firewall includes.
You can have $iot_devices,$guest_devices,$kidz_devices in one rule
Better try chrony or ntp.org ntpd for some accuracy, but yes the busybox ntp will serve too.
Yes, the device uses the IP address, but it rotates constantly and you need to do a DNS query every time you check the site.
So, the device will still do DNS queries, but it gets resolved from the cache and only the A record is returned. It's basically using the router to do pre-processing of the full query by stripping all of the DNSSEC baggage, so the query response fits into one packet and doesn't need to restart the query using TCP (in order to handle the multi-packet response, which a lot of cheap/small/old IoT devices don't support in their DNS stack).
You lost me.
The suggested rules use the firewall to redirect the packet to your server instead. The rule I linked above is running on my device.