NTP not able to use ipv6 peer

[gunnarf]

I’ve tried a lot of servers including 2.pool.ntp.org and swedish Stupi servers, with the same result. So I guess nothing will be better with the ones you suggest. After restarting the fw I got new peers. Tried ntpdate -q with all these new servers. That works like a charm

[Patrick M. Hausen]

You could DM me the output of "pfctl -s all" if you like.

[gunnarf]

You could DM me the output of "pfctl -s all" if you like.

Done

[Patrick M. Hausen]

I will have a look at it after work.

[gunnarf]

I will have a look at it after work.

Did you get time to look at my pfctl output?

[Patrick M. Hausen]

Sorry, took longer than expected. I cannot see anything obvious in the rules. You seem to have two states for packets sent out to NTP peers with your IPv6 address as the source, but no answer received:

Code: [Select]

all udp 2001:9b0:40::967c:56c9[123] -> 2003:a:87f:c37c::4[123]       SINGLE:NO_TRAFFIC
all udp 2001:9b0:40::967c:56c9[123] -> 2001:440:1880:7373::2[123]       SINGLE:NO_TRAFFIC

Have you looked at the firewall live view while e.g. restarting ntpd?

Kind regards,
Patrick

[gunnarf]

Have you looked at the firewall live view while e.g. restarting ntpd?

Kind regards,
Patrick

I'll give it a try. Is there some filtering options while watching? There is a lot of traffic going on, since the server is remote via vpn. Some live "grep" for wanted packages. Or can I record the session and watch in wireshark?

[newsense]

I'll make two quick suggestions:

1) For testing, remove all but one NTP source in your config, one of the PTB sources Patrick suggested earlier in the thread will suffice. Remove DNS of the equation as well, use on the IPv6 IP.

2) Consider NTS, all the PTB servers support it and a few others. There's no justification for UDP/123 over the Internet. This chrony directive can help where a battery is not present on the device and it is only used for the initial synchronization due to SSL constraints

Code: [Select]

<ntsnocert>1</ntsnocert>

[gunnarf]

I'll make two quick suggestions:

1) For testing, remove all but one NTP source in your config, one of the PTB sources Patrick suggested earlier in the thread will suffice. Remove DNS of the equation as well, use on the IPv6 IP.

2) Consider NTS, all the PTB servers support it and a few others. There's no justification for UDP/123 over the Internet. This chrony directive can help where a battery is not present on the device and it is only used for the initial synchronization due to SSL constraints

Code: [Select]

<ntsnocert>1</ntsnocert>

The only result I get from only setting up NTP-servers with only ipv6, is that I get no time sync at all.

And setting up NTPsec in OPNsense, that obviously doesn't support it, seems a little to much effort.Digging into setup files that only should be touched by OPNsense, seems a little bit too much interfering with the system for my taste.

[gunnarf]

Just as an experiment, I set up my laptop with Ubuntu, to check if I can get ipv6 NTP responds from there. I can not! Setting up ipv6-enabled NTP-servers in the ntp.conf gives that they stop at .INIT. No sync! When I change to ipv4 NTP-servers, I can immediately get things started.

And for fun I tried ntpdate -d against time.cloudflare.com

root@OPNsense:~ # ntpdate -d time.cloudflare.com
23 Jul 16:20:54 ntpdate[24260]: ntpdate 4.2.8p17@1.4004-o Wed Jun 21 00:58:29 UTC 2023 (1)
transmit(2606:4700:f1::1)
transmit(2606:4700:f1::123)
transmit(162.159.200.123)
receive(162.159.200.123)
transmit(162.159.200.1)
receive(162.159.200.1)
transmit(2606:4700:f1::1)
transmit(2606:4700:f1::123)
transmit(162.159.200.123)
receive(162.159.200.123)
transmit(162.159.200.1)
receive(162.159.200.1)
transmit(2606:4700:f1::1)
transmit(2606:4700:f1::123)
transmit(162.159.200.123)
receive(162.159.200.123)
transmit(162.159.200.1)
receive(162.159.200.1)
transmit(2606:4700:f1::1)
transmit(2606:4700:f1::123)
transmit(162.159.200.123)
receive(162.159.200.123)
transmit(162.159.200.1)
receive(162.159.200.1)
2606:4700:f1::1: Server dropped: no data
2606:4700:f1::123: Server dropped: no data

server 162.159.200.123, port 123
stratum 3, precision -25, leap 00, trust 000
refid [10.128.9.203], root delay 0.000763, root dispersion 0.000137
reference time:      e867b598.6ca44811  Sun, Jul 23 2023 16:20:08.424
originate timestamp: e867b5cd.18a0dc10  Sun, Jul 23 2023 16:21:01.096
transmit timestamp:  e867b5cd.185138a4  Sun, Jul 23 2023 16:21:01.094
filter delay:  0.02754    0.02740    0.02715    0.02718
               ----       ----       ----       ----
filter offset: +0.000395  +0.000298  +0.000386  +0.000387
               ----       ----       ----       ----
delay 0.02715, dispersion 0.00002, offset +0.000386

server 162.159.200.1, port 123
stratum 3, precision -25, leap 00, trust 000
refid [10.128.9.203], root delay 0.000748, root dispersion 0.000092
reference time:      e867b5bc.f698a7b4  Sun, Jul 23 2023 16:20:44.963
originate timestamp: e867b5cd.4a023365  Sun, Jul 23 2023 16:21:01.289
transmit timestamp:  e867b5cd.49ba9672  Sun, Jul 23 2023 16:21:01.288
filter delay:  0.02727    0.02716    0.02722    0.02719
               ----       ----       ----       ----
filter offset: +0.000294  +0.000235  +0.000236  +0.000256
               ----       ----       ----       ----
delay 0.02716, dispersion 0.00000, offset +0.000235

23 Jul 16:21:02 ntpdate[24260]: adjust time server 162.159.200.123 offset +0.000386 sec

[newsense]

Here are the steps for NTS on OPNsense:

1. Remove all NTP sources from Services-NetworkTIme-General - Save changes >> Service is now stopped.

2. Install os-chrony plugin

3. Configure Chrony, enable both NTS checkboxes, set port to 123, add preferred NTS Peers and Allowed Networks - Save changes

[gunnarf]

Here are the steps for NTS on OPNsense:

1. Remove all NTP sources from Services-NetworkTIme-General - Save changes >> Service is now stopped.

2. Install os-chrony plugin

3. Configure Chrony, enable both NTS checkboxes, set port to 123, add preferred NTS Peers and Allowed Networks - Save changes

That will do nothing. Tried with its on a raspberry pi. It is the fact that communication is ipv6 that stops it from working. As soon as I remove the ipv6-enabled NTP servers it works like a charm. So no meaning to install crony for NTS support.

[Patrick M. Hausen]

If you can reproduce the issue with Ubuntu it's probably going back to your ISP ...

[gunnarf]

If you can reproduce the issue with Ubuntu it's probably going back to your ISP ...

I thought so too, but I had a conversation with my ISP technical support, and they claim they have no block on port 123 with ipv6. And as you saw, when I ran ntpdate -q to an ipv6 server, I got a connection Weird is the word. Maybe I should let them make a ticket on the issue, so they test by themselves?

[CJ]

I have found that ISP support usually doesn't know what they're talking about, especially when involving IPv6.

If you have access to a remote VM you can try something like netcat, etc and see if you can connect to it over 123.  You can get some VMs for free but I'm not sure what the limitations are.