NTP not working

1

Hello everyone,

I’ve been trying to configure NTP on my OPNsense setup, but it’s not working. I have a double NAT setup. I contacted my ISP, and they confirmed they don’t block NTP traffic. In fact, if I connect a device directly to the internet router, NTP works without issues.

I’m wondering if the double NAT could be causing the problem, perhaps due to port translation. I also tried:

  • Setting NAT mode to hybrid

  • Adding a rule on my WAN interface for static ports

…but I still can’t get it to work. I’m concerned that multiple things might be misconfigured and that fixing one might expose another misconfiguration, making it difficult to identify the correct combination.

Additionally, here’s what I see in the logs:

2>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="20"] Listen normally on 1 lo0 [::1]:123
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="21"] Listen normally on 2 lo0 [fe80::1%4]:123
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="22"] Listen normally on 3 lo0 127.0.0.1:123
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="23"] Listening on routing socket on fd #24 for interface updates
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="24"] 0.0.0.0 8811 81 mobilize assoc 61758
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="25"] 0.0.0.0 8811 81 mobilize assoc 61759
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="26"] kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="27"] 0.0.0.0 c01d 0d kern kernel time sync enabled
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="28"] kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="29"] 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
<102>1 2026-02-05T11:45:50+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="30"] 0.0.0.0 c016 06 restart
<102>1 2026-02-05T11:45:52+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="31"] Soliciting pool server 172.233.111.111
<102>1 2026-02-05T11:45:53+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="32"] Soliciting pool server 178.215.228.24
<101>1 2026-02-05T11:45:53+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="33"] ntpd exiting on signal 15 (Terminated)
<102>1 2026-02-05T11:45:53+01:00 opnsense.x.com ntpd 55069 - [meta sequenceId="34"] 0.0.0.0 8812 82 demobilize assoc 61759

Has anyone faced a similar issue or could suggest how to properly configure NTP in a double NAT scenario on OPNsense?

I’m also attaching a picture of my network diagram for reference: image hosted at ImgBB — ImgBB

Thanks in advance!

2

Hi mb, welcome.

Sounds like you are doing double-NAT. This can be troublesome, especially with applications using UDP (such as NTP). Other people have experienced similar issues (see link).

Solution in this case was to put ISP modem into bridge mode and have only one router (Opnsense).

3

Hi,

Thanks! no way :joy: you redirected me to my own post but on another forum.

Unfortunately, the router in bridge mode is not an option for now.

I was mainly looking for guidance on LAN/WAN/NAT rules that could be interfering without me realising it, rather than a network-level solution, or perhaps if there is some peculiarity of the NTP protocol that we were overlooking. Or a way to diagnose it.

The tcpcump of the interface doesn’t say much, and this command:

ntpdate -dv 0.es.pool.ntp.org

has this output:

erver 212.227.145.233, port 123
stratum 2, precision -24, leap 00, trust 000
refid [152.78.229.49], root delay 0.036499, root dispersion 0.037933
reference time:      ed2f082e.0567378f  Thu, Feb  5 2026 13:14:38.021
originate timestamp: ed2f0db7.430a798f  Thu, Feb  5 2026 13:38:15.261
transmit timestamp:  ed2f0db6.707ebb4b  Thu, Feb  5 2026 13:38:14.439
filter delay:  0.04776    0.04517    0.05122    0.04518
               ----       ----       ----       ----
filter offset: +0.813946  +0.812655  +0.815561  +0.812643
               ----       ----       ----       ----
delay 0.04517, dispersion 0.00067, offset +0.812655

 5 Feb 13:38:14 ntpdate[42776]: step time server 172.233.111.111 offset +0.805528 sec

however, this other one:

root@opnsense:~ # ntpq -p
     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.000
 1.es.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 2.pool.ntp.org  .POOL.          16 p    -   64    0    0.000   +0.000   0.000

On the other hand, I’m still waiting for my ISP to respond regarding forwarding UDP port 123 inbound from my router’s WAN to OPNsense.

I also checked this post link, and I also get “ntpd exiting on signal 15 (Terminated)” :pensive_face:

4

Ha, lol.

I am not aware of any limitations (routing-wise) within NTP protocol or implementations (Chrony, NTPD) that would cause your setup not to work. Doule-NAT is a pain in more cases than just NTP.

Unfortunately I have insufficient technical insight in how to tackle your situation.

Personally i use OPNsense aswell, but i do not have Double-NAT.

1 Like
5

ntpdate -d will use an unprivileged source port while ntpd will use 123 as the source port. Maybe your rules handle that differently?

What does tcpdump show, or what does “doesn’t say much” mean?

6

Hi,

thanks, yess you’re right, we were looking at that too → link

I’m attaching the tcpdump output:

root@opnsense:/var/log/ntpd # tcpdump -i igb0 -n host 192.168.10.2 and port 123 -v
tcpdump: listening on igb0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:58:22.518577 IP (tos 0x0, ttl 63, id 18493, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.10.2.47385 > 172.233.111.193.123: NTPv4, Client, length 48
        Leap indicator:  (0), Stratum 0 (unspecified), poll 10 (1024s), precision 32
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   2772191361.503535152 (1987-11-06T13:09:21Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 2772191361.503535152 (1987-11-06T13:09:21Z)
15:58:22.527672 IP (tos 0xb8, ttl 54, id 12366, offset 0, flags [DF], proto UDP (17), length 76)
    172.233.111.193.123 > 192.168.10.2.47385: NTPv4, Server, length 48
        Leap indicator:  (0), Stratum 2 (secondary reference), poll 10 (1024s), precision -23
        Root Delay: 0.040298, Root dispersion: 0.004913, Reference-ID: 0x5223a292
          Reference Timestamp:  3979292295.229266776 (2026-02-05T14:58:15Z)
          Originator Timestamp: 2772191361.503535152 (1987-11-06T13:09:21Z)
          Receive Timestamp:    3979292303.312032695 (2026-02-05T14:58:23Z)
          Transmit Timestamp:   3979292303.312052196 (2026-02-05T14:58:23Z)
            Originator - Receive Timestamp:  +1207100941.808497542
            Originator - Transmit Timestamp: +1207100941.808517043
15:58:38.098439 IP (tos 0xb8, ttl 64, id 63084, offset 0, flags [none], proto UDP (17), length 76)
    192.168.10.2.123 > 84.77.195.114.123: NTPv4, Client, length 48
        Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6 (64s), precision -24
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3979292318.098346456 (2026-02-05T14:58:38Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3979292318.098346456 (2026-02-05T14:58:38Z)
15:58:39.027917 IP (tos 0xb8, ttl 64, id 63951, offset 0, flags [none], proto UDP (17), length 76)
    192.168.10.2.123 > 195.95.153.59.123: NTPv4, Client, length 48
        Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6 (64s), precision -24
        Root Delay: 0.000000, Root dispersion: 0.000015, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3979292319.027843405 (2026-02-05T14:58:39Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3979292319.027843405 (2026-02-05T14:58:39Z)
15:58:41.226909 IP (tos 0xb8, ttl 64, id 16815, offset 0, flags [none], proto UDP (17), length 76)
    192.168.10.2.123 > 5.250.191.170.123: NTPv4, Client, length 48
        Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6 (64s), precision -24
        Root Delay: 0.000000, Root dispersion: 0.000045, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3979292321.226833268 (2026-02-05T14:58:41Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3979292321.226833268 (2026-02-05T14:58:41Z)
15:58:48.117743 IP (tos 0x0, ttl 63, id 54597, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.10.2.6180 > 172.233.111.193.123: NTPv4, Client, length 48
        Leap indicator:  (0), Stratum 0 (unspecified), poll 6 (64s), precision 32
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   1099448618.213777692 (1934-11-04T02:23:38Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 1099448618.213777692 (1934-11-04T02:23:38Z)
15:58:48.126503 IP (tos 0xb8, ttl 54, id 28444, offset 0, flags [DF], proto UDP (17), length 76)
    172.233.111.193.123 > 192.168.10.2.6180: NTPv4, Server, length 48
        Leap indicator:  (0), Stratum 2 (secondary reference), poll 6 (64s), precision -23
        Root Delay: 0.040298, Root dispersion: 0.005279, Reference-ID: 0x5223a292
          Reference Timestamp:  3979292295.229266776 (2026-02-05T14:58:15Z)
          Originator Timestamp: 1099448618.213777692 (1934-11-04T02:23:38Z)
          Receive Timestamp:    3979292328.910292478 (2026-02-05T14:58:48Z)
          Transmit Timestamp:   3979292328.910318915 (2026-02-05T14:58:48Z)
            Originator - Receive Timestamp:  +2879843710.696514786
            Originator - Transmit Timestamp: +2879843710.696541222
15:59:01.107802 IP (tos 0xb8, ttl 63, id 10408, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.10.2.19220 > 195.95.153.43.123: NTPv4, Client, length 48
        Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   795814392.603232797 (1925-03-21T19:33:12Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 795814392.603232797 (1925-03-21T19:33:12Z)
15:59:01.120660 IP (tos 0xb8, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 76)
    195.95.153.43.123 > 192.168.10.2.19220: NTPv4, Server, length 48
        Leap indicator:  (0), Stratum 1 (primary reference), poll 0 (1s), precision -23
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: GNSS
          Reference Timestamp:  3979292337.000000000 (2026-02-05T14:58:57Z)
          Originator Timestamp: 795814392.603232797 (1925-03-21T19:33:12Z)
          Receive Timestamp:    3979292341.903768487 (2026-02-05T14:59:01Z)
          Transmit Timestamp:   3979292341.903771953 (2026-02-05T14:59:01Z)
            Originator - Receive Timestamp:  +3183477949.300535689
            Originator - Transmit Timestamp: +3183477949.300539155
^C

We had a rule that allowed all types of NAT outbound UPD traffic because we use WireGuard and set it up that way.

However, I’ve created one for NTP-UDP with static ports and placed it on top the other one.

Although I don’t understand/not sure why they have to be set as “static”, bc I thought NAT already kept track of which host the source port belonged to​:thinking:

7

Just stopped here to chide those who say that IPv6 is an inconvenient burden because IPv4 NAT makes it irrelevant. Shame on you!

Please, forgive me my intrusion and carry on.

1 Like