StarLink as source for NTP

luckman212

I have a firewall nat outbound rule set up like this to prevent pfSense from rewriting the source port ensuring it's 123 in case Starlink demands seeing the request from port 123

@Mission-Ghost that doesn't seem to be a good idea to me. I haven't tested, but since pfSense's builtin ntpd is already bound to port 123, rewriting the source port for all outgoing NTP queries to 123 feels like it would create an impossible situation where any replies from the dish would get eaten by the ntpd daemon instead of being routed to the ntpq client.

Mission-Ghost

@luckman212 I'm also not confident it's a good idea, but I'd like to rule out possibilities until it works. Then I can back up until it doesn't work and have a good idea of what's required then.

Alternatives are certainly invited and appreciated.

I know the Startlink time server is there and works, and even pfSense command-line ntpdate will get it without all these hokey rules, but the pfSense NTP service can't get the time from the same server. There must be a reason why but I haven't found it or heard it yet.

Ramosel

Latest from Starlink:

Your setup in bypass mode allows the Starlink dish (at 192.168.100.1) to remain reachable for basic queries, as shown by your successful ntpdate -q 192.168.100.1 command from the pfSense shell and pings from LAN clients. This confirms connectivity and that the dish's Stratum 1 GPS-based NTP server responds to one-off NTP queries.The issue with pfSense's built-in NTP service (ntpd) showing reach 0 in ntpq -p stems from compatibility problems between pfSense's older ntpd implementation and the Starlink dish's NTP server. The dish's NTP server responds correctly to simple queries (like ntpdate) but does not fully poll or associate properly with standard ntpd in some third-party router setups, including pfSense. This is a known behavior reported by multiple users in bypass mode.

Recommended SolutionsSwitch to Chrony (preferred and widely reported fix):
pfSense supports installing Chrony via the package manager (available in recent versions). Many users have resolved exact "ntpd won't poll but ntpdate works" issues by switching to Chrony, which handles the dish's NTP responses better. Go to System > Package Manager > Available Packages, search for and install "chrony".
Configure it under Services > Chrony to use 192.168.100.1 as your primary server.
Disable the built-in NTP service if needed.

Fallback options: Keep using external NTP pools (like the NIST or pool.ntp.org servers you already have) as backups—they're working fine in your output.
For LAN clients having issues pointing directly to 192.168.100.1, configure them to use pfSense's IP as their NTP server instead (pfSense can relay or serve time once it's synced).

No firewall rule changes or support intervention are typically needed, as the dish's NTP service (UDP 123) is always enabled and reachable in bypass mode when basic access works. The problem is specifically ntpd's polling behavior with this particular server implementation. Switching to Chrony should get consistent reachability and synchronization.

Mission-Ghost

@Ramosel I went looking for Chrony a day or two ago and even on 25.07.1 the package manager does not list it nor does search find it.

I wasn't sure if I wanted to go get and use an unsupported package but if pfSense's NTP is fundamentally incompatible with the Starlink NTP server, then maybe this is the only option.

I'll look into unsupported-Chrony more.

chpalmer

Well.. Looks like some new comments needed here..

https://redmine.pfsense.org/issues/16058

https://redmine.pfsense.org/issues/10404

Ramosel

@Mission-Ghost said in StarLink as source for NTP:

I went looking for Chrony a day or two ago and even on 25.07.1

Yeah, I'm on SG-4860s with pfSense+ ver. 25.11-RELEASE and I'm not seeing Chrony in the Package Manager either.

Stephen? Still watching this one? Is Chrony only available on certain hardware?

Rick

luckman212

@Ramosel There's no Chrony package for pfSense that I'm aware of. Maybe Starlink support was confused on that or got misled by some AI. Who knows.

There are FreeBSD packages however, so you could try to install and configure it via the commandline.

pkg add -f https://pkg.freebsd.org/FreeBSD:16:amd64/latest/All/chrony-lite-4.8.pkg

or if you need the "fat" version that supports NTS for some reason:

pkg add -f https://pkg.freebsd.org/FreeBSD:16:amd64/latest/All/chrony-4.8.pkg

stephenw10

@Ramosel said in StarLink as source for NTP:

Is Chrony only available on certain hardware?

No it's not in our repo. Yet.

@Ramosel said in StarLink as source for NTP:

The dish's NTP server responds correctly to simple queries (like ntpdate) but does not fully poll or associate properly with standard ntpd

Hmm, that seems like BS to me! Hard to imagine what it would be doing differently. But I also imagine, if that really is the case, then ntpd could be tuned to send something it allows.

stephenw10

@luckman212 said in StarLink as source for NTP:

Maybe Starlink support was confused on that or got misled by some AI

Ha, yup. Do they even have support or is it just Grok.....

But, assuming they are real, it sounds like multiple other users have hit this previously in other OSs. So there may well already be some discussion to be found somewhere....

dennypage

@Ramosel I don't believe chrony is available in the pfSense distribution for any hardware.

It's an old topic:

https://forum.netgate.com/topic/106105/chrony

There are only four main NTP options:

Classic NTPd. This is what pfSense packages. Includes direct support for serial GPS. MIT/BSD license.
NTPsec. Secure replacement for NTPd. BSD/MIT license. Requires gpsd to support serial GPS.
OpenNTPD. Alternative NTP implementation as part of OpenBSD. BSD License. IIRC, no support for GPS.
Chrony. Advanced NTP implementation. GPLv2 license. Requires gpsd to support serial GPS. Supports hardware timestamps. Default for many/most Linux distributions.

I use Chrony everywhere but pfSense.

luckman212

@dennypage Why does Chrony being GPLv2 licensed prohibit it from being included pfSense? In my understanding, as long as Chrony remains separate (not directly integrated into some closed source part of pfSense) then it doesn't violate that license, and pfSense itself would not then be forced to be GPL2 itself. Is that incorrect?

stephenw10

Looking at some pcaps I can see no difference at all between queries from ntpd when initialises and those from ntpdate.

That's against an ntpd server. Check a pcap against the starlink disk when using ntpdate. See if it's doing something odd. I'd be very surprised if it is though....

Ramosel

@stephenw10 said in StarLink as source for NTP:

No it's not in our repo. Yet.

Well... Hopefully, "Yet" is a good thing.
I'd like to get this working, but don't need it "now".

It looks like all the Linux distros are dropping or have dropped ntpdate, So I guess it's an inevitable shift to Chrony or systemd-timesyncd. I'm assuming there is no fundamental difference between nptdate for Linux and FreeBSD?

Rick

johnpoz

Seems odd that chrony would work, but not the latest version of ntp, I show 25.11 using the latest ntp that I am aware of 4.2.8p18

Would be curious to see the pcap of send from chrony vs one from ntp.. normal ntp can for sure query chrony.. I run chrony myself on my pi ntp server. but most of my clients are just running normal ntp client.

Patch

@dennypage said in StarLink as source for NTP:

I use Chrony everywhere but pfSense.

Same, as it is far more accurate at tracking the references time.
As a result I do not use pfsence as a time server.
However I would love to see pfsense move to chrony as pfense is well placed to provide time to all devices on my network.

elvisimprsntr

@Patch

Do you have POWERD enabled?

Screenshot 2026-01-05 at 5.30.28 AM.png

I have it disabled and GPS+PPS disciplined NTP server is accurate on a Protectli FW4C

https://github.com/elvisimprsntr/pfsense-ntp-gps

stephenw10

@johnpoz said in StarLink as source for NTP:

Seems odd that chrony would work, but not the latest version of ntp,

Yup. Even more odd that it responds to an ntp query from ntpdate but not queries from ntpd. hey are essentially the same as far as I can see.

elvisimprsntr

@stephenw10

NTPDATE and CHRONY both use random source ports, whereas NTPD uses source port 123

Also, does Starlink support iburst? If not, it might stop responding or send KOD. PCAPs would let you know.

stephenw10

Hmm, a clue perhaps! Some state issue in the starlink router then maybe.

Though that isn't the case in pfSense(FreeBSD?). If you run ntpdate it will fail if ntpd is running because it tries to use the same source port. But only if you try to actually update the system clock. If you run with query only or debug it uses a non-privileged port and succeeds:

[25.11-RELEASE][admin@5100.stevew.lan]/root: ntpdate 172.21.16.1
 5 Jan 14:15:46 ntpdate[49624]: the NTP socket is in use, exiting
[25.11-RELEASE][admin@5100.stevew.lan]/root: ntpdate -q 172.21.16.1
server 172.21.16.1, stratum 3, offset -0.004204, delay 0.02602
 5 Jan 14:15:51 ntpdate[51456]: adjust time server 172.21.16.1 offset -0.004204 sec

@Mission-Ghost Can you test that after stopping ntpd? That would prove it if it's a port issue.

stephenw10

Even if it objects to iburst it should still respond to the first query. As understand it a pcap shows no replies at all. Also I think Chrony also uses iburst by default. But that could potentially be an issue I agree.