Help Troubleshooting OPNsense as LAN NTP Server (Service Status Pending)

Started by mb19, Today at 08:30:33 AM

Previous topic - Next topic
Hi everyone,

I'm trying to configure my OPNsense server (version OPNsense 25.7.7_4-amd64) as an NTP server for my LAN devices. My network layout looks like this:

                Internet
                    │
                    │
        ┌─────────────────────────┐
        │   Router ISP                                                   .│
        │     192.168.10.1                                                 .│
        └─────────────────────────┘
                    │
                    │ (192.168.10.0/24)
                    │
        ┌─────────────────────────┐
        │       OPNsense                                               .│
        │                                                                          .│
        │ WAN: igb0                                                    .│
        │   IP: 192.168.10.2/24                                     .│
        │                                                                          .│
        │ LAN: igb1                                                       .│
        │   IP: 192.168.45.1/24                                     .│
        │                                                                           .│
        │ OPT1: em0 ( empty )                                   .│
        └─────────────────────────┘
                    │
                    │ (LAN 192.168.45.0/24)
                    │
        ┌─────────────────────────┐
        │      LAN                                                            .│
        │   (192.168.45.0/24)                                        .│
        └─────────────────────────┘

When I run the following command on a LAN computer and on OPNsense:

--> tcpdump -ni igb0 udp port 123

I get:

PC - LAN:   192.168.45.18.35966 > 5.250.184.159.123: NTPv4, Client, length 48
OpnSense:   192.168.10.2.21172   > 5.250.184.159.123: NTPv4, Client, length 48

OpnSense:   5.250.184.159.123 > 192.168.10.2.21172:   NTPv4, Server, length 48
PC - LAN:   5.250.184.159.123 > 192.168.45.18.35966: NTPv4, Server, length 48

If I'm understanding this correctly:

1 - We can see NTP requests from the LAN reaching OPNsense
2 - OPNsense then forwards them to the router, which sends them out to the NTP pool server
3 - The NTP server replies
4 - The router forwards the reply back to OPNsense
5 - OPNsense performs the de-NAT and delivers the response to the LAN client


If this interpretation is correct, then I think I can rule out DNS issues or ISP-side blocking of NTP traffic.

However, in the OPNsense GUI the NTP service status is always shown as "pending", which makes me suspect that the issue is happening somewhere around this point in the network diagram:


                Internet
                    │
                    │
        ┌─────────────────────────┐
        │   Router ISP                                                   .│
        │     192.168.10.1                                                 .│
        └─────────────────────────┘
                    │
                    │ (192.168.10.0/24)
                    │<-----------------------------------HERE
        ┌─────────────────────────┐
        │       OPNsense                                               .│
        │                                                                          .│
        │ WAN: igb0                                                    .│
        │   IP: 192.168.10.2/24                                     .│
        │                                                                          .│
        │ LAN: igb1                                                       .│
        │   IP: 192.168.45.1/24                                     .│
        │                                                                          .│
        │ OPT1: em0 ( empty )                                   .│
        └─────────────────────────┘
                    │
                    │ (LAN 192.168.45.0/24)
                    │
        ┌─────────────────────────┐
        │      LAN                                                            .│
        │   (192.168.45.0/24)                                        .│
        └─────────────────────────┘

I'm not sure whether I'm misunderstanding a concept (and therefore troubleshooting in the wrong direction), or if this is a technical issue I'm missing. The goal is simply to use OPNsense as an NTP server for the LAN.

Any help or guidance would be greatly appreciated.
Thanks!

This is not how NTP works.

OPNsense runs an NTP server that synchronises itself with public servers on the Internet. Once a synchronised state is reached that server directly answers requests by all local clients.

The "pending" is normal for the pool entries. But there should be one server labeled as "Active Peer" and some more labeled as "Candidate". If that is the case all is well.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

I'm not sure I'm understanding this correctly. When I run the command on OPNsense, I get the following output:

root@opnsense:/var/log/filter # ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.004
 1.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.004
 2.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.004
 3.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.004
 0.europe.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.004
root@opnsense:/var/log/filter #

From what I understand, OPNsense isn't able to synchronize with the public NTP servers.

On the other hand, I still don't fully understand where the "Active Peer" and "Candidate" indicators are supposed to appear.

I'm attaching an image of my GUI as well:

https://ibb.co/yzGMS25
https://ibb.co/1YFJmnpN

I've so far seen two cases where NTP fails to sync:

1) local DNS is broken (for the firewall itself, not the LAN) so it can't resolve the pools
2) system date is too far out of sync with the local time (like when CMOS battery dies) and NTP refuses to sync

#2 can be fixed by setting the date manually with the 'date' command to within ~5 minutes of the actual time, then NTP starts to work.

You are right - you do not have any active peers. The output should look similar to this one:
$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 2.freebsd.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.000
+94.16.122.152   131.188.3.222    2 u  754 1024  377    2.674   -0.052   1.608
+78.46.87.46     189.97.54.122    2 u  217 1024  377    0.434   -0.297   0.117
-46.38.241.235   189.97.54.122    2 u  600 1024  377    2.654   -1.037   0.401
*141.144.241.16  195.145.119.188  2 u  435 1024  377    5.366   -0.225   0.043

So the pool entries stay as they are but there should be individual servers *from* these pools that are active peers or candidates, respectively.
The states "pending", "active peer", "candidate" are shown in the UI status page if all is correct.

You can try on OPNsense e.g.:

$ drill  0.europe.pool.ntp.org
[...]
0.europe.pool.ntp.org.    130    IN    A    185.123.84.51
0.europe.pool.ntp.org.    130    IN    A    51.250.68.198
0.europe.pool.ntp.org.    130    IN    A    46.160.198.122
0.europe.pool.ntp.org.    130    IN    A    87.63.200.138

$ ntpdate -q 185.123.84.51

You do have your NTP service enabled on all interfaces (the default), do you?
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Thanks to both of you.

On the one hand, I don't think this is a DNS issue, since name resolution does work:

root@opnsense:/var/log/filter # dig pool.ntp.org

; <<>> DiG 9.20.15 <<>> pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60156
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pool.ntp.org.                  IN      A

;; ANSWER SECTION:
pool.ntp.org.           130     IN      A       162.159.200.1
pool.ntp.org.           130     IN      A       195.95.153.59
pool.ntp.org.           130     IN      A       194.164.164.175
pool.ntp.org.           130     IN      A       92.113.12.77

;; Query time: 454 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Dec 11 11:06:49 CET 2025
;; MSG SIZE  rcvd: 105

And on the other hand, my system clock is also correct (I'm in Spain) and here's the output:

root@opnsense:/var/log/filter # date
Thu Dec 11 11:08:38 CET 2025
root@opnsense:/var/log/filter #


https://ibb.co/QF2bkBcm


Here is the drill test as well:

root@opnsense:/var/log/filter # drill  0.europe.pool.ntp.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 22650
;; flags: qr rd ra ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 0.europe.pool.ntp.org.       IN      A

;; ANSWER SECTION:
0.europe.pool.ntp.org.  130     IN      A       193.219.94.180
0.europe.pool.ntp.org.  130     IN      A       193.1.8.98
0.europe.pool.ntp.org.  130     IN      A       193.32.222.35
0.europe.pool.ntp.org.  130     IN      A       188.225.9.167

;; Query time: 581 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Dec 11 11:11:23 2025
;; MSG SIZE  rcvd: 103
root@opnsense:/var/log/filter #

Finally, I've tried different combinations about the interfaces (out of lack of knowledge and some desperation, hoping that one of them would work by elimination).

In the screenshot I shared earlier I only had LAN selected, but I can leave it by default with all of them, I restart the service, and it still remains in "pending":

https://ibb.co/TxjNtrpj

Synchronisation takes a while and of course the service *must* be active on WAN or it cannot communicate with the public NTP servers.

Did you try the ntpdate command? Sometimes ISPs block NTP and ask people to only use the servers provided by them. NTP can be used for reflection DDoS attacks if configured improperly.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Hi, yes

For example rn the WAN interface is active:

root@opnsense:~ # cat /var/etc/ntpd.conf
#
# Autogenerated configuration file
#

tinker panic 0
# Orphan mode stratum
tos orphan 1
# Max number of associations
tos maxclock 10


# Upstream Servers
pool 0.es.pool.ntp.org iburst maxpoll 9 prefer
pool 1.es.pool.ntp.org maxpoll 9
pool 2.es.pool.ntp.org maxpoll 9
pool 3.es.pool.ntp.org maxpoll 9
pool 0.europe.pool.ntp.org maxpoll 9


enable stats
statistics clockstats loopstats peerstats
statsdir /var/log/ntp
logconfig =syncall +clockall +peerall +sysall
driftfile /var/db/ntpd.drift
restrict source
restrict default
restrict -6 default
restrict 127.0.0.1
restrict ::1
interface ignore all
interface ignore wildcard
interface listen 127.0.0.1
interface listen ::1
interface listen fe80::1%lo0
interface listen 192.168.45.1
interface listen 10.20.0.1
interface listen 192.168.10.2
root@opnsense:~ #

I also read that there could be issues if there is double NAT, as well as with WireGuard, but I'm still lacking some networking knowledge in that area. In any case, here's the process with both WAN and LAN enabled (I stopped and restarted the service in foreground mode):

root@opnsense:/var/log/filter # service ntpd stop
ntpd does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable
root@opnsense:/var/log/filter # ps axu | grep ntpd
root    67417   0.0  0.1  24776   8436  -  Ss   11:19        0:00.19 /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf
root    83127   0.0  0.0  13744   2396  0  S+   11:52        0:00.00 grep ntpd
root@opnsense:/var/log/filter # kill 67417
root@opnsense:/var/log/filter # ps axu | grep ntpd
root    99634   0.0  0.0  13744   2408  0  S+   11:52        0:00.00 grep ntpd
root@opnsense:/var/log/filter # ntpd -n -d -c /var/etc/ntpd.conf
11 Dec 11:52:55 ntpd[3110]: ntpd 4.2.8p18@1.4062-o Wed Oct 22 02:05:50 UTC 2025 (1): Starting
11 Dec 11:52:55 ntpd[3110]: Command line: ntpd -n -d -c /var/etc/ntpd.conf
11 Dec 11:52:55 ntpd[3110]: ----------------------------------------------------
11 Dec 11:52:55 ntpd[3110]: ntp-4 is maintained by Network Time Foundation,
11 Dec 11:52:55 ntpd[3110]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
11 Dec 11:52:55 ntpd[3110]: corporation.  Support and training for ntp-4 are
11 Dec 11:52:55 ntpd[3110]: available at https://www.nwtime.org/support
11 Dec 11:52:55 ntpd[3110]: ----------------------------------------------------
11 Dec 11:52:55 ntpd[3110]: proto: precision = 0.838 usec (-20)
11 Dec 11:52:55 ntpd[3110]: basedate set to 2025-10-10
11 Dec 11:52:55 ntpd[3110]: gps base set to 2025-10-12 (week 2388)
11 Dec 11:52:55 ntpd[3110]: initial drift restored to 0.000000
11 Dec 11:52:55 ntpd[3110]: Listen normally on 0 igb0 192.168.10.2:123
11 Dec 11:52:55 ntpd[3110]: Listen normally on 1 igb1 192.168.45.1:123
11 Dec 11:52:55 ntpd[3110]: Listen normally on 2 lo0 [::1]:123
11 Dec 11:52:55 ntpd[3110]: Listen normally on 3 lo0 [fe80::1%4]:123
11 Dec 11:52:55 ntpd[3110]: Listen normally on 4 lo0 127.0.0.1:123
11 Dec 11:52:55 ntpd[3110]: Listen normally on 5 wg0 10.20.0.1:123
11 Dec 11:52:55 ntpd[3110]: Listening on routing socket on fd #26 for interface updates
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 8811 81 mobilize assoc 20628
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 8811 81 mobilize assoc 20629
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 8811 81 mobilize assoc 20630
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 8811 81 mobilize assoc 20631
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 8811 81 mobilize assoc 20632
11 Dec 11:52:55 ntpd[3110]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 c01d 0d kern kernel time sync enabled
11 Dec 11:52:55 ntpd[3110]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
11 Dec 11:52:55 ntpd[3110]: 0.0.0.0 c016 06 restart
11 Dec 11:52:56 ntpd[3110]: Soliciting pool server 92.113.12.78
11 Dec 11:52:58 ntpd[3110]: Soliciting pool server 195.20.235.143
11 Dec 11:52:58 ntpd[3110]: Soliciting pool server 194.164.164.175
11 Dec 11:52:59 ntpd[3110]: Soliciting pool server 94.143.139.219
11 Dec 11:53:00 ntpd[3110]: Soliciting pool server 178.62.68.79
11 Dec 11:54:01 ntpd[3110]: Soliciting pool server 162.159.200.123
......

Regarding the ISP, I spoke with the provider a few months ago to ask if they were blocking the traffic, but they told us they were not

The status is still like this:

root@opnsense:~ # ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 1.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 2.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 3.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 0.europe.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001

Double NAT? Do you have a router in front of your OPNsense?
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Yes, it's the diagram I posted earlier. Wait, I'll upload a photo:  https://ibb.co/svfB6bdc


So what I literally have is a router, OPNsense is connected to that router, and also connected to that router there is a switch for the LAN (it's not managed, so I had also ruled that out as a problem) 🤔🤔

Forward UDP port 123 inbound from your router's WAN to OPNsense.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Sorry, but you mean on the router and not on the OPNsense, right?