Next NTP Unreach/Pending issue. not working at all.

[SerErris]

Hi I have to admin I never had so much issues with any NTP-Server setup than with OPNSense. I am out of ideas.

I have now read here in the forums on many threads that have the same issue, but no avail.

I have different issues for different parts.

For the first part I have just setup the simplest possible NTP-Server setup with a single NTP Server from my Provider (Telekom).

The ntp server is ntp1.t-online.de. Its IP Address is 2003:2:2:140:194:25:134:196, which is pingable, but does not seem to react ...

Also i can use ntpdate on ntp1.t-online.de which then resolves to an IPv4 address and at least it works. However ntpq does not work and does not get any answer.

Code Select Expand

clinden@firewall:~ % sudo ntpdate -v -b ntp1.t-online.de
15 Feb 21:01:45 ntpdate[56745]: ntpdate 4.2.8p18@1.4062-o Tue Jan 21 04:04:45 UTC 2025 (1)
15 Feb 21:01:51 ntpdate[56745]: step time server 194.25.134.196 offset +0.000596 sec
clinden@firewall:~ %
clinden@firewall:~ % ntpq -pn 194.25.134.196
194.25.134.196: timed out, nothing received
***Request timed out
I have attached the settings of my NTP Server section. In another thread I read that for pools (which I ultimately want to use) I need to disable the "Deny packets that attempt a peer association". ALso I disabled the Disable ntpq and ntpdc queries.

But nothing results in any change of behaviour.

I have also added the status page .. it is stuck there even if we can see Delay and Offset Values. ...

But it simply does not work never works. I am out of ideas on what the cause can be.

I also looked at my IPv6 settings, which is in line with recommendations for telekom, and I can ping6 the ipv6 address from the server.
I can also see the pass message in the firewall rule for the icmp, but I cannot see any ntp package, nut sure how to search for it.

Also I am struggeling to understand how the answer of an UDP packet shall every come back to the ntp client on the firewall?

In the firewall rules on my WAN interface I have no rules defined (only automatic rules are setup) and in LAN only the default LAN to any rule and LAN IPv6 to any rule.

No floating rule as well (only automatic)

[SerErris]

Okay it seems I did NOT read the main documentation on it. Even if it sounds counter intuitive, you need to put the WAN and the LAN network into Interfaces... doo..

okay now can anyone please send me a screenshot of the default Access restrictions settings? I am not sure I can remember them or reset them to default in any easy way.

I am just assuming that defaults would be most secure.

[Patrick M. Hausen]

How is your NTP service supposed to contact a server on the internet via the LAN interface?

Change "Interfaces" back to "All (recommended)" and NTP will work. There's a reason for the "recommended" word in that setting. Don't touch, afterwards.

[Patrick M. Hausen]

See screen shot for my settings. The external servers are the official PTB (Physikalisch-Technische Bundesanstalt) time sources for Germany: ptbtime[1-4].ptb.de. They officially encourage the use of their infrastructure, only ask to use these only to sync one (or maybe two or three) servers per location/data centre/whatever and point all client systems at your own central server(s).

192.168.1.6 is my stratum 1 GPS time source.

HTH,
Patrick

[SerErris]

Yeh I just implied that this is "listening interfaces" which I did not want to have the WAN interface in. But yeah I got it RTFM, which I actually did not and it does not say it in the GUI directly. BTW "ALL" Is not a selectable option.

Thanks for the settings.

I also learned something new on IPv6. Which is NAT64 and DNS64. As all my clients can still use IPv4 I now disabled DNS64 addresses as I have not setup NAT64 and have not really a clue on what I am supposed to do. Therefore anyhow any DNS64 response is unreachable as my firewall will not route it.

But that is a topic for another time. Fore now - I am glad this could be resolved.

Thanks again.

[Patrick M. Hausen]

If you do not select anything, the setting will be "All".

The point is that not selecting any interface will result in the service listening on 0.0.0.0, also known as INADDR_ANY, which is the default and most stable setting.

If you set interfaces explicitly, then e.g. unplug and replug that particular cable, the service in question (SSH, NTP, DNS, ...) will simply stop listening on that interface and not recover without a restart. Peculiarity of the socket API and not easy to fix.

That's why the "recommended" is there. Just leave it at that for all interfaces. For security/access control there are firewall rules. Who cares if the service is listening on WAN? Did you create a firewall rule permitting access? You didn't? So ...? :-)

As for NAT64 - this is for IPv6 only systems to access IPv4 addresses on the Internet.

Whenever an IPv6 systems asks for an AAAA record of some server - e.g. github.com - which only has IPv4, so A record, the DNS64 server translates that IPv4 response into a special IPv6 address starting with 64:ff9b.

So e.g. github.com - 140.82.121.4 - becomes 64:ff9b::8c52:7904. The IPv6 only system opens a connection to the supposedly IPv6 reachable system at that address and NAT64 takes care of translating to IPv4.

So if you only have IPv4 NAT64 is not for you. There is no NAT46, because the IPv6 address space is so vastly larger than the legacy internet, it's just not possible. While you can easily fit all IPv4 addresses into two words of an IPv6 address as demonstrated. Repeating myself: this is for IPv6 only systems.

HTH,
Patrick

[SerErris]

The main point of DNS64 is to run for IPv6 only networks (which I anyhow do not have, but dual stack).

The wording in the Unbound->General settings for DNS64 is not explicit enough for my liking:

If this option is set, Unbound will synthesize AAAA records from A records if no actual AAAA records are present.

However the documentation is much clearer on this:

Enable DNS64 so IPv6-only clients can reach IPv4-only servers. If enabled, Unbound synthesizes AAAA records for domains which only have A records. DNS64 requires NAT64 to be useful, e. g. the Tayga plugin or a third-party NAT64 service. The DNS64 prefix must match the IPv6 prefix used be the NAT64.

This help sentence would prevent many users in home networks to enable it, or at least recognize, that you do need Tayga plugin to also have NAT64.

Anyhow, problem solved, user issue - case closed.

[Patrick M. Hausen]

The main point of DNS64 is to run for IPv6 only networks

Which is exactly what I wrote about NAT64 and DNS64 ...