How to redirect IPv4 *and* IPv6 NTP traffic

ChrisJenk

I have the fairly common problem whereby I have a lot of 'client' devices which seem to use hardcoded NTP server names, which they then resolve in order to use NTP. Sadly these devices do not respect the NTP server addresses provided to them via DHCP[6]. I want all of these devices to use the time servers in my LAN rather than their random set of external time servers.

I started down the path of DNS redirection (via Pi-Hole). That does mostly work but the set of potential names needing redirection is quite large and it is easy to miss one now or in the future. A more robust approach would perhaps to be to redirect all client NTP traffic in the LAN that tries to target external NTP servers back to my own servers. I've seen several articles that show how to use NAT port forwarding on the LAN interface to achieve this, and indeed that works for IPv4. However...

When setting up the port forwarding NAT I have to choose IPv4 or IPv6. I tried setting up an identical IPv6 port forwarding NAT as the IPv4 one but when I try to save it it complains that:

The destination port range overlaps with an existing entry.

Any idea how I can redirect IPv6 NTP traffic alongside IUPv4 NTP traffic?

Gertjan

@ChrisJenk said in How to redirect IPv4 *and* IPv6 NTP traffic:

I have the fairly common problem whereby I have a lot of 'client' devices which seem to use hardcoded NTP server names, which they then resolve in order to use NTP. Sadly these devices do not respect the NTP server addresses provided to them via DHCP[6]. I want all of these devices to use the time servers in my LAN rather than their random set of external time servers.

Yeah, that's known.
They ask for a lease, you'll stuff in there an NTP address, and then the devices don't care, and use their own 'hard coded' host names.

As pfSense can be an NTP server, you could use this pfSense documentation suggestion as shown here. This is the one I use to redirect NTP (port 123 UDP) traffic with destination to some IP, redict to the LAN pfSense IP, port 123 where the pfSense NTP is happy to serve the request.
You'll sync the pfSense NTP client with your local (LAN based) NTP server on your LAN, and now you'll be good.

On your LAN, first rule, a NAT firewall rule that redirects all UDP port 123 traffic to the pfSense LAN IPv4 or localhost 127.0.0.1.
On your LAN, next rule : block all IPv4 UDP destination port 123 traffic.

And check your devices if they still mange to get their time, proving that your NAT NTP setup works, because if the can't, you have an issue, as no time means : broken TLS, or worse.

Why this double step ?
As you can't (imho - afaik) use a pfSense NAT rule that NAT's back out / the incoming NAT traffic is also the outgoing NAT traffic.
But maybe it's possible ... you tell me - I hope to be wrong ^^

Btw : make the same rules for IPv6.

@ChrisJenk said in How to redirect IPv4 *and* IPv6 NTP traffic:

Any idea how I can redirect IPv6 NTP traffic alongside IUPv4 NTP traffic?

Create IPv4 rules from IPv6 rules.
Don't fall for the

trap. Don't use it ^^

stephenw10

You could probably just block v6 ntp and redirect v4 for simplicity.

ChrisJenk

@stephenw10 @Gertjan

Thanks for the pointers; my solution, which seems to be working, is:

pfSense NTP service is (was already) configured to sync with my local servers. Made sure it is listening on LAN, DMZ and Localhost.
Block all outbound IPv6 NTP traffic on the LAN interface, unless it originates from my time servers.
NAT all outbound IPv4 NTP traffic on the LAN interface to the DMZ interface, unless it originates from my time servers. So all 'bad' clients will use pfSense as their time server, which ultimately means they are using my local servers.

This seems to have achieved the desired result, but I will of course monitor carefully for several days in case it has broken anything.

johnpoz

@ChrisJenk another thing you can do is just create a host override for what they are looking for and point it to your local ntp server(s).. I have some iot devices that insist on using pool.ntp.org..

Which btw doesn't even return a IPv6 address.. So curious what your devices are using for ntp that does return IPv6. Only the 2.pool.ntp.org returns IPv6.

Anyway - just create a host override to point what they are using at your local ntp server. Or a redirect - so for example stuff using anything.pool.ntp.org gets my ntp server

local-zone: "pool.ntp.org" redirect
local-data: "pool.ntp.org 3600 IN A 192.168.3.32"

my roomba at least is using its vendor fqdn

2025-05-31 23:14:23 		AAAA	3.irobot.pool.ntp.org	iRobot.home.arpa	1.2 ms	
2025-05-31 23:14:23 		A	3.irobot.pool.ntp.org	iRobot.home.arpa	1.2 ms	
2025-05-31 23:14:23 		AAAA	2.irobot.pool.ntp.org	iRobot.home.arpa	1.1 ms	
2025-05-31 23:14:23 		A	2.irobot.pool.ntp.org	iRobot.home.arpa	1.3 ms	
2025-05-31 23:14:23 		AAAA	1.irobot.pool.ntp.org	iRobot.home.arpa	1.1 ms	
2025-05-31 23:14:23 		A	1.irobot.pool.ntp.org	iRobot.home.arpa	1.3 ms	
2025-05-31 23:14:23 		AAAA	0.irobot.pool.ntp.org	iRobot.home.arpa	1.1 ms	
2025-05-31 23:14:23 		A	0.irobot.pool.ntp.org	iRobot.home.arpa	1.2 ms

Since I have dns redirect for anything pool.ntp.org domain - they all return my local ntp server

;; QUESTION SECTION:
;3.irobot.pool.ntp.org.         IN      A

;; ANSWER SECTION:
3.irobot.pool.ntp.org.  3600    IN      A       192.168.3.32

Couple of things that annoy me about the whole thing - is any vendor that wants to use pool.ntp is suppose to register a vendor fqdn for use with the ntp pool. Another thing is some Iot devices I have one that insist on using uk.ntp when they are clearly meant and sold in the US.

If your device you sell needs time, then you should allow for adjustment of what time source they use - be it actually honor what is handed out via dhcp, or allow the ntp servers to be set on the device..

Really unrelated, but another thing that bugs me about iot devices is if you are going to have them talk to something every X minutes or hours.. Have the common courtesy to cache what you get back from dns for the length of the ttl.

ChrisJenk

@johnpoz I don't use pfSense for DNS; I have two separate authoritative servers (for resilience) for my various home domains and these are front-ended by a pair of Pi-Hole servers (again for resilience) for ad-blocking purposes (only some systems point at the Pi-Hole servers). I did set up what are essentially 'host overrides' in my DNS servers but those then affected my local timeservers too. Also, from network snooping, I could see that the number of overrides needed would be quite large and it would be easy to miss one now, or in the future when I added more devices, and the maintenance burden could be moderate.

The NTP traffic redirect solution (which is now working for both IPv4 and IPv6 - I have unblocked IPv6 NTP requests) excludes my local timeservers so they can still send requests to the real external servers while everything else is coerced to using my local servers.

As far as IPv6 goes I have a policy that as far as possible everything I use will be dual stack (of course that isn't 100%) so I always endeavour to implement solutions that cover both. I do actually also have a couple of smart home / IoT devices that send NTP requests via IPv6 as well as IPv4 (Flic hub and Netatmo video doorbell).

2.pfsense.pool.ntp.org returns IPv4 and IPv6 addresses as do many other sub-pools of pool.ntp.org (though not pool.ntp.org itself, as you note).

As for everything else you said, I could not agree more! It's pretty annoying when you have to jump through these kinds of hoops instead of just being able to configure the devices as you want, or have them at least respect what I give them via DHCP[6]. And the super chatty DNS in some is also stupid; clearly they don't understand caching and TTL. Sigh.

JKnott

@ChrisJenk said in How to redirect IPv4 *and* IPv6 NTP traffic:

Any idea how I can redirect IPv6 NTP traffic alongside IUPv4 NTP traffic?

What I did was find what host name they were using and created an alias to my home server.