Redirect NTP Servers - Solve
Some clients ignore DHCP Option 42 or are hardcoded to public NTP servers. This script transparently redirects all LAN NTP (UDP 123) traffic to a local server using iptables + ipset.
Tested on Firewalla Gold (Box Version 1.980 / Stable) — works perfectly.
My setup:
- Local GPS/NTP server: 192.168.88.45 (Pi-hole + chrony + GPS HAT)
- LAN subnet: 192.168.88.0/23 (i.e. .88.1 through .89.254)
- Goal: Redirect all clients except .88.45 to .88.45 for NTP
Installation:
- Save the script to: /home/pi/.firewalla/config/post_main.d/ntp_redirect.sh
- Make executable: chmod +x ntp_redirect.sh
- Firewalla will auto-run after every reboot.
Why this method?
Because the built-in Services → NTP Intercept toggle doesn’t cut it:
- You still have to manually rewrite ntp.conf
- Any custom rules are ephemeral (wiped on reboot)
- Firewalla doesn’t give you fine control over which clients get intercepted
This script fixes that. It’s durable, precise, and doesn’t fight you every time you reboot.
#!/bin/bash
# Compatible with: Firewalla Gold / Gold Plus
# Version: 1.980 (3e707d3c) Stable Release
# Purpose: Redirect NTP traffic from clients ignoring DHCP Option 42
set -euo pipefail
# Config
IPSET_NAME="ntp_clients"
DEST_IP="192.168.88.45"
TAG_FILE="/home/pi/.firewalla/config/post_main.d/ntp_redirect_done"
# Remove old DNAT rule (if any)
sudo iptables -t nat -D PREROUTING -i br0 -p udp --dport 123 \
-m set --match-set $IPSET_NAME src \
-j DNAT --to-destination ${DEST_IP}:123 2>/dev/null || true
# Create or flush ipset
if ! sudo ipset create $IPSET_NAME hash:ip 2>/dev/null; then
sudo ipset flush $IPSET_NAME
fi
# Add all clients in 192.168.88.0/23, excluding .88.45
for i in $(seq 1 254); do
[ "$i" -eq 45 ] && continue
sudo ipset add $IPSET_NAME 192.168.88.$i
done
for i in $(seq 0 254); do
sudo ipset add $IPSET_NAME 192.168.89.$i
done
# Bypass redirect for the NTP server itself
sudo iptables -t nat -C PREROUTING -i br0 -p udp --dport 123 \
-s ${DEST_IP} -j RETURN 2>/dev/null || \
sudo iptables -t nat -I PREROUTING -i br0 -p udp --dport 123 \
-s ${DEST_IP} -j RETURN
# Redirect matching clients to the local NTP server
sudo iptables -t nat -C PREROUTING -i br0 -p udp --dport 123 \
-m set --match-set $IPSET_NAME src \
-j DNAT --to-destination ${DEST_IP}:123 2>/dev/null || \
sudo iptables -t nat -A PREROUTING -i br0 -p udp --dport 123 \
-m set --match-set $IPSET_NAME src \
-j DNAT --to-destination ${DEST_IP}:123
# Tag file (Firewalla uses this for tracking)
sudo touch "$TAG_FILE"
How to verify if it is working:
On the Pi-hole / NTP server, run:
chronyc clients
Look for incoming requests from your LAN clients.
On Firewalla, try:
sudo tcpdump -n -i any udp port 123 and host 192.168.88.45
or:
sudo iptables -t nat -L PREROUTING -n -v | grep 123
You should see redirected requests from clients originally trying to hit public NTP servers.
-
Firewalla’s NTP Intercept just reroutes clients to Firewalla’s own internally-defined NTP pool servers. My setup is different — I run a GPS-based Stratum 1 time server and want every client on my network to use it.
DHCP Option 42 can advertise my server, but many devices ignore it — including PlayStation 5 consoles, smart TVs, IoT gear, iPhones, Android phones, and more. These devices don’t let you manually define a time server.
By transparently redirecting all UDP/123 traffic to my server, I control where my network gets its time — not the other way around.
-
That’s a terrific question — and I have several reasons, in no particular order:
- My network averages 55–75 DHCP clients, not counting TVs and game systems. With kids, their friends, a house full of IoT gear, and the occasional mystery device, there’s a lot going on.
- I like controlling the variables. When I found Firewalla’s NTP Intercept doesn’t let you define your own servers, I wanted that option.
- After 30+ years in IT, I know DHCP Option 42 is often ignored by modern devices. I prefer deciding exactly where they get their time.
- My Pi-hole/Chrony/dnsmasq setup grew into adding a DS3231 RTC (since the Pi 5 lacks one), which led me to GPS time sync.
- The SB Components GPS HAT was too flimsy, so I upgraded to the Uputronics GPS/RTC Expansion Board — far more reliable.
- And honestly, because I can. If you’ve bought a Firewalla instead of using an ISP’s stock gateway, you probably want the same flexibility and configurability I do.
- Even with FTTH (rock solid), I run a T-Mobile 5G gateway for failover.
At the end of the day, Firewalla is rock-solid out of the box. I just wanted to push it further. Shell scripting gives me that freedom — and it’s a harmless way to have fun and learn something new.
Please sign in to leave a comment.
Comments
4 comments