StarLink as source for NTP

Ramosel

A while back I used a raspberry pi build with a custom hat and GPS to build a Stratum 1 time server. It's all working well, but... it is yet another device I have to manage and power as I move closer to be being off-grid.

I was also a beta tester for StarLink and occasionally still get requests to try small updates for function because I run their router in bypass as I use and SG-4860 and pfSense+ as my primary router.

In a discussion I had in December with one of their guys he said they do provide access to Stratum 1 NTP service through their dish at address 192.168.100.1. I had setup a rule to get access to my dish a while back when testing was intense but haven't really used it much the last year or so and now it doesn't seem to be passing data.

Is anyone else using StarLink to access NTP? Any snags on the allow rule to 192.168.100.0 subnet?

Thanks,
Rick

johnpoz

@Ramosel have no idea what your going on about to be honest.. But yeah simple google says they provide ntp.. It sure isn't stratum 1 from this

https://starlink.com/support/article/0873e885-831a-9f4e-4808-2838a28f2e69
Does Starlink provide time synchronization or NTP servers?

They provide access to the internet - right, so you should be able to talk to any ntp server you want.. Only issue would be delay and jitter.

Any snags on the allow rule to 192.168.100.0 subnet?

Why would you think you need a special rule for that, or that it would be an issue - out of the box lan can talk to any any, so yeah you would be able to talk to that IP.. If you can get to it, since its rfc1918. And pfsense rules allow it to talk to anything.. There would be no need for any special rule??

Ramosel

@johnpoz
From the white paper I received:
Starlink provides a built-in NTP (Network Time Protocol) server on the dish itself (often called "Dishy"), using highly accurate GPS-derived time (Stratum 1 level). This feature became available around mid-2024 and is confirmed in official Starlink support documentation.

How to Access It
The NTP server is reachable at the IP address 192.168.100.1 on your local network.

If you're using the standard Starlink router (not in bypass mode), devices on your Wi-Fi or Ethernet network can directly query this IP for time synchronization.
Configure your device's NTP client to point to 192.168.100.1 (e.g., in Windows/Linux/macOS time settings, or in tools like chrony/ntpd on servers).

If Using a Third-Party Router (Bypass Mode)

The dish's IP (192.168.100.1) may not be directly reachable from your main LAN.
In this case:Add a static route on your third-party router to direct traffic to 192.168.100.1 via the Starlink router/gateway.

Then configure your devices or NTP clients to use 192.168.100.1.

Notes

This is a best-effort service; Starlink notes they cannot guarantee perfect accuracy, though user reports show excellent performance (often better than internet-based NTP due to direct GPS sourcing).

The dish may occasionally reboot (e.g., overnight), briefly interrupting the NTP service.
For the official confirmation, check the Starlink support article on time synchronization.

chpalmer

@Ramosel If you can ping 192.168.100.1 through your pfSense from a client device then pfSense box can utilize your Starlink for its NTP if programmed to do so from the Services /NTP page.

I can reach my cable modem that uses the same 192.168.100.1 address from my desktop here so I already know that it should work for you.

johnpoz

@Ramosel so they run a ntp services on their device - ok..

Still not understanding what your question is? Why would you think you need to do anything special on pfsense to access that?

Pfsense does not block outbound rules to any address, out of the box if pfsense can talk to it, so would any client behind pfsense.

The only thing about rfc1918 is being able to talk to it - it doesn't route over the public internet. If the address is on your isp network, or your isp device they provide you.. Be it a modem, an ont, a starlink sat device etc.. Pfsense should be able to talk to it - if pfsense is connected to that device or the isp. There are no special rules you would have to do..

Only issue is if maybe this 192.168.100.1 is another IP than what your wan network of of pfsense ip.. ie a different L3 on the same L2.. If that is the case you could create a vip on pfsense wan to put it in the same network - say 192.168.100.2 You may or may not have to do this..

but there our countless threads about talking to modems IP 192.168.100.1 when pfsense gets a public IP on its wan.

If that is your issue - can show example of doing a vip if you need that sort of help, but there really isn't any sort of firewall rule you need to do.

Personally I would prob just setup pfsense ntp service to get time from that 192.168.100.1, and then point your clients to your pfsense for ntp.

Ramosel

@johnpoz

I can ping the 192.168.100.1 address and get a response with 400 to 600ms returns.
I cannot reach it via a browser (didn't really expect it to). At one time you could reach stats/status on the dish even if you were running in bypass by using 192.168.100.1/statistics. But I believe those screens are only on the enterprise versions of Starlink now. (they are on the phone/tablet app)

I can pint 192.168.1.1 (pfSense/sg-4860) and get responses with 100 to 200ms

If I use 192.168.100.1 as the first and preferred NTP server and my local r-pi NTP server as the secondary, the NTP service always bypasses the 192.168.100.1 and uses the 192.168.1.40 (GPS hanging off my deck cabled to r-pi).

Not knowing if the system tests but uses the quickest return, I gave the r-pi a bad address on the NTP setup page and it system then skipped to a tertiary server (NIST).

So, what I've been asking is HOW do I get pfSense to see the NTP server at the 192.169.100.1 address?
Seems I need a static route, but I'm not even sure about that since I can get a ping.

Rick

luckman212

@Ramosel have you followed this guide?

https://docs.netgate.com/pfsense/en/latest/recipes/modem-access.html

Ramosel

@johnpoz

John, this was sent this afternoon... But it actually turns off my ability to ping.

Yes, the Starlink dish at 192.168.100.1 will respond to pings when the router is in bypass mode and you're using pfSense as your third-party router — but only after proper configuration.Why Extra Setup Is Required with pfSenseIn bypass mode, the Starlink router passes traffic directly, and pfSense's WAN gets a CGNAT IP (e.g., 100.64.x.x). The dish's management interface (192.168.100.1) sits on a separate internal network, so LAN devices (or even pfSense diagnostics) can't reach it without help. A simple static route often isn't enough due to how pfSense handles NAT and source addressing.The standard, widely confirmed method (from Netgate forums, Reddit, and user guides) involves:Adding a Virtual IP (VIP) on the WAN interface:Go to Firewall > Virtual IPs > Add.
Type: IP Alias.
Interface: WAN (your Starlink interface).
Address: Something like 192.168.100.2/24 (any unused IP in the subnet except .1).
Description: "Starlink Dish Access".

Creating a Manual Outbound NAT Rule:Go to Firewall > NAT > Outbound > Switch to "Manual Outbound NAT" or "Hybrid".
Add a new rule at the top:Interface: WAN.
Source: Your LAN network (e.g., 192.168.1.0/24 or any).
Destination: 192.168.100.0/24 (or specifically 192.168.100.1/32).
Translation Address: The VIP you created (e.g., 192.168.100.2).

Save and Apply Changes.

This makes traffic to 192.168.100.1 appear to come from an IP on the same subnet, allowing the dish to respond (including ICMP pings).Verification from UsersMany pfSense + Starlink users report successful pings (e.g., constant pings for monitoring dish uptime) and access to the debug page/NTP after this setup.
Without it → pings timeout (no route/reply).
Also recommended: On the WAN interface, reject DHCP leases from 192.168.100.1 to prevent fallback issues.

Once configured, you can ping 192.168.100.1 from pfSense Diagnostics > Ping or any LAN device. This also enables the built-in NTP server.If you run into issues (e.g., specific pfSense version), share a screenshot of your VIP/NAT rules, and I can troubleshoot further!

chpalmer

@Ramosel said in StarLink as source for NTP:

@johnpoz

I can ping the 192.168.100.1 address and get a response with 400 to 600ms returns.

I can pint 192.168.1.1 (pfSense/sg-4860) and get responses with 100 to 200ms

If I use 192.168.100.1 as the first and preferred NTP server and my local r-pi NTP server as the secondary, the NTP service always bypasses the 192.168.100.1 and uses the 192.168.1.40 (GPS hanging off my deck cabled to r-pi).

Not knowing if the system tests but uses the quickest return, I gave the r-pi a bad address on the NTP setup page and it system then skipped to a tertiary server (NIST).

Those are long ping times if you are pinging from your local LAN on that pfSense box.. As comparison my ping time to my local pfSense box here is less than 1ms and to my attached modem also less than 1ms.

If you can ping 192.168.100.1 you do not need a static route for that address.

What is your ping time to 192.168.1.40 ??

What is your ping time if you use the ping tool in the pfSense "Diagnostics" menu?

johnpoz

@Ramosel said in StarLink as source for NTP:

If you run into issues (e.g., specific pfSense version), share a screenshot of your VIP/NAT rules, and I can troubleshoot further!

Who are you talking to? I need no assistance that is for sure.. And sure and the hell know how to setup a simple vip and nat to it.. So guess I will go back to my original comment?

I have no idea what your going on about.. heheh

And with @chpalmer about those ping times - if you are taking 400 to 600ms to ping 192.168.100.1 it sure and the hell isn't local on your starlink device - those are sat delay sorts of response times.. I can ping china with better response times ;)

If you were pinging your local device you should see something more like

$ ping 192.168.100.1

Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63

Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

That is me pinging my modem, that yes has a 192.168.100.1 address for its management interface, that I have a vip and nat setup to get to, etc.

Ramosel

@chpalmer

My bad those ping times were .xxx

My Stratum 1 GPS response times are .140 to .240 ms

Ping times are much the same as from my debian workstation one WAP away.

And I agree, I shouldn't need a static address. And if you read my post from Starlink this afternoon the Virtual IP route is actually blocking my ping to 192.168.100.1

johnpoz

@Ramosel said in StarLink as source for NTP:

.140 to .240 ms

Really? Those seem pretty freaking low even for a lan.. 1/2 a ms ok, but 0.00014 of a second.. Those are pinging yourself sort of of responses..

From 127.0.0.1: bytes=60 seq=0001 TTL=128 ID=23c2 time=0.119ms
From 127.0.0.1: bytes=60 seq=0002 TTL=128 ID=23cc time=0.195ms
From 127.0.0.1: bytes=60 seq=0003 TTL=128 ID=23ea time=0.192ms
From 127.0.0.1: bytes=60 seq=0004 TTL=128 ID=23ec time=0.229ms

This seems a bit more realistic for pinging something on the same lan..

From 192.168.10.10: bytes=60 seq=0001 TTL=64 ID=3568 time=0.760ms
From 192.168.10.10: bytes=60 seq=0002 TTL=64 ID=3644 time=0.452ms
From 192.168.10.10: bytes=60 seq=0003 TTL=64 ID=37d4 time=0.436ms
From 192.168.10.10: bytes=60 seq=0004 TTL=64 ID=37e1 time=0.401ms

Reponse times to some across a wire in the .1ms range your talking highspeed trading network sorts of speed.

Ramosel

@johnpoz

John, I know you are the sharpest knife in the drawer when it comes to this stuff and I learn a ton from you. But it seems you're not seeing the forest for the trees on this one. ;-)

Let me "Break it down".
There is supposed to be a GPS based time server on the StarLink dish. It is supposed to be at 192.168.100.1

My pfSense LAN is on 192.168.1.1

I can ping the the dot 100.1 devices from a dot 1.1 device.
I cannot get the time server response on 100.1 from pfSense's NTP server configuration.
IF I try to use the prescribed methods (static mapping, above, previous post) I actually lose the ability to ping the 100.1 device.

As per your pings vs mine.
My workstation I'm on is one hop away from pfSense on an ethernet connection on a WAP with backhaul.
When I ping my existing time server from my workstation, I get:
$ ping 192.168.1.40
PING 192.168.1.40 (192.168.1.40) 56(84) bytes of data.
64 bytes from 192.168.1.40: icmp_seq=1 ttl=64 time=0.169 ms
64 bytes from 192.168.1.40: icmp_seq=2 ttl=64 time=0.171 ms
64 bytes from 192.168.1.40: icmp_seq=3 ttl=64 time=0.213 ms
64 bytes from 192.168.1.40: icmp_seq=4 ttl=64 time=0.135 ms

or

ping -A 192.168.1.40
PING 192.168.1.40 (192.168.1.40) 56(84) bytes of data.
64 bytes from 192.168.1.40: icmp_seq=1 ttl=64 time=0.222 ms
64 bytes from 192.168.1.40: icmp_seq=2 ttl=64 time=0.168 ms
64 bytes from 192.168.1.40: icmp_seq=3 ttl=64 time=0.127 ms
64 bytes from 192.168.1.40: icmp_seq=4 ttl=64 time=0.221 ms

when I ping from pfSense's diagnostic ping, I get:

PING 192.168.1.40 (192.168.1.40): 56 data bytes
64 bytes from 192.168.1.40: icmp_seq=0 ttl=64 time=0.240 ms
64 bytes from 192.168.1.40: icmp_seq=1 ttl=64 time=0.148 ms
64 bytes from 192.168.1.40: icmp_seq=2 ttl=64 time=0.182 ms

--- 192.168.1.40 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.148/0.190/0.240/0.038 ms

I don't see a lot of difference. Am I wrong? Asking because I don't know what you expect.

edit: forgot to post:
If the route to 100.1 is working I get:
$ ping -A 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=0.463 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=0.336 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=63 time=0.330 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=63 time=0.355 ms

Rick

Mission-Ghost

@Ramosel this is an interesting service I was unaware of.

I get similar pings to the dish you do. I can also get to the dish page. But when I add the dish ip address and “prefer” to my pfsense (Netgate 4200) ntp service as a server I get “unreach/pending.”

So although I can ping and reach the dish address with http I am unable to get ntp from the same address. I have no virtual ip, static route or other special configurations for ping and http access to the dish.

I’d love to make this work. I can run the command ntpdate -q 192.168.100.1 in Diagnostics/Command Prompt and receive the following auspicious response but ntp service is still stuck in unreach/pending:

server 192.168.100.1, stratum 1, offset +0.000507, delay 0.02887
3 Jan 23:06:28 ntpdate[69996]: adjust time server 192.168.100.1 offset +0.000507 sec

This seems to show FreeBSD can query starlink ntp server, the server is running and returning plausible values, but the pfsense ntp service cannot.

stephenw10

Yeah if ping works you should be able to query it for ntp with ntpdate like that and it should show the server stratum.

If your local system time is too far out it may refuse to sync to it. Otherwise it should show the correct reach value after some time.

Mission-Ghost

@stephenw10 I’ll try again and let it run longer. Local system time is already within a couple of dozen milliseconds due to being synced with nist servers. What’s strange is the nist servers reach shows as 1 almost immediately but the starlink server, on the roof of my house, stays at 0 and does not get the time even after running for minutes, but ntpdate in the command page instantly returns the time from the dish. Sure suggests something isn’t working right with the ntp service. I’ll try again and expect different results. Film at 11.

Update: ntp service has been trying dish for 40 min and still unreach. Nist servers all 377 reach. Can’t reach dish ntp from LAN node either, but I can still get to dish page with http from same lan node. What could be blocking access to dish ntp server when ntpdate on pfsense command window works?

chpalmer

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

Update: ntp service has been trying dish for 40 min and still unreach. Nist servers all 377 reach. Can’t reach dish ntp from LAN node either, but I can still get to dish page with http from same lan node. What could be blocking access to dish ntp server when ntpdate on pfsense command window works?

Maybe you need to set some type of login/Authentication??

Is there an instruction set that you can access from Starlink themselves?

down at the bottom of the settings page in pfSense..

"Enable NTPv3 authentication (RFC 1305)"

https://starlink.com/support/article/0873e885-831a-9f4e-4808-2838a28f2e69 seems to say it should just work. Can you sync to it from your client device direct??

https://community.ntppool.org/t/starlink-enables-ntp-server-with-gps-time-for-local-use/3520

chpalmer

PING 192.168.1.40 (192.168.1.40): 56 data bytes
64 bytes from 192.168.1.40: icmp_seq=0 ttl=64 time=0.240 ms
64 bytes from 192.168.1.40: icmp_seq=1 ttl=64 time=0.148 ms
64 bytes from 192.168.1.40: icmp_seq=2 ttl=64 time=0.182 ms

or

PING 192.168.1.40 (192.168.1.40): 56 data bytes
64 bytes from 192.168.1.40: icmp_seq=0 ttl=64 time=240 us
64 bytes from 192.168.1.40: icmp_seq=1 ttl=64 time=148 us
64 bytes from 192.168.1.40: icmp_seq=2 ttl=64 time=182 us

milliseconds vs microseconds.

In the simulcast audio world we deal in microseconds.. ;)

stephenw10

I mean if ntpdate returns data against it I'd expect it to work. It doesn't appear to require authentication. It could be returning something unusual ntpdate isn't showing perhaps.

Does it respond to ntpq?

[2.8.1-RELEASE][admin@t70.stevew.lan]/root: ntpq -np 172.21.16.1
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.20.0    .GPS.            0 l    8   16  377    0.000  -68.085   2.691
 0.pfsense.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.001
*131.111.8.63    197.205.52.7     2 u    6   64  377    6.838  +11.139   0.351
+131.111.8.60    197.205.52.7     2 u   37   64  377    6.141  +11.052   0.447
+185.139.7.67    139.143.5.30     2 u   15   64  377    7.200  +11.412   0.563

Note that whilst that claims to be stratum 0 it's a USB connected GPS and hence has crap jitter so isn't actually selected for use. But it has the expected reach values.

johnpoz

I would sniff - one to validate ntpd is actually sending and 2nd to see what you get back exactly.. Your reach should go up pretty quick if its actually answering.. If your just seeing 0 either your not actually sending to it - its not answering or what it sends back ntp is ignoring for some reason.