NTP not able to use ipv6 peer

[gunnarf]

OK, do you see any requests going out on port 123 with tcpdump when you restart ntpd?

I ran tcpdump -v -i igb0 | grep NTP:

20:43:31.748331 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) h-2001-9b1-10d-39--1-bed3.na.bahnhof.se.ntp > ntp1.time.nl.ntp: [udp sum ok] NTPv4, length 48
20:43:47.660810 IP6 (flowlabel 0x10d00, hlim 63, next-header UDP (17) payload length: 56) h-2001-9b1-c395-d000-cf5-588-2910-7645.na.bahnhof.se.65048 > 2a01:b740:a30:4000::1f2.ntp: [udp sum ok] NTPv4, length 48
20:43:49.662217 IP6 (flowlabel 0xe0b00, hlim 63, next-header UDP (17) payload length: 56) h-2001-9b1-c395-d000-cf5-588-2910-7645.na.bahnhof.se.57976 > 2a01:b740:a30:4000::1f2.ntp: [udp sum ok] NTPv4, length 48
20:43:51.663633 IP6 (flowlabel 0x40e00, hlim 63, next-header UDP (17) payload length: 56) h-2001-9b1-c395-d000-cf5-588-2910-7645.na.bahnhof.se.62243 > 2a01:b740:a08:4000::1f2.ntp: [udp sum ok] NTPv4, length 48
    198.235.24.175.50674 > h-82-196-108-106.A980.priv.bahnhof.se.ntp: NTPv4, length 48
    h-82-196-108-106.A980.priv.bahnhof.se.ntp > sth1.ntp.netnod.se.ntp: NTPv4, length 48
    sth1.ntp.netnod.se.ntp > h-82-196-108-106.A980.priv.bahnhof.se.ntp: NTPv4, length 48
    h-82-196-108-106.A980.priv.bahnhof.se.ntp > ntp1.flashdance.cx.ntp: NTPv4, length 48
    ntp1.flashdance.cx.ntp > h-82-196-108-106.A980.priv.bahnhof.se.ntp: NTPv4, length 48
20:44:35.791691 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) h-2001-9b1-10d-39--1-bed3.na.bahnhof.se.ntp > ntp1.time.nl.ntp: [udp sum ok] NTPv4, length 48
    h-82-196-108-106.A980.priv.bahnhof.se.ntp > sth2.ntp.netnod.se.ntp: NTPv4, length 48
    sth2.ntp.netnod.se.ntp > h-82-196-108-106.A980.priv.bahnhof.se.ntp: NTPv4, length 48

[Patrick M. Hausen]

Could you do that with -n and show an ifconfig output of your WAN interface and the netstat -rn output?

[gunnarf]

Could you do that with -n and show an ifconfig output of your WAN interface and the netstat -rn output?

tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
    82.196.108.106.123 > 147.78.228.41.123: NTPv4, length 48
    147.78.228.41.123 > 82.196.108.106.123: NTPv4, length 48
09:56:45.292265 IP6 (flowlabel 0x533a5, hlim 63, next-header UDP (17) payload length: 56) 2001:9b1:c395:d000:e51:1ff:fee2:88b4.65486 > 2a01:b740:a08:3000::1f2.123: [udp sum ok] NTPv3, length 48
    82.196.108.106.29485 > 120.25.115.20.123: NTPv4, length 48
    120.25.115.20.123 > 82.196.108.106.29485: NTPv4, length 48
09:57:05.312632 IP6 (flowlabel 0x0f8ea, hlim 63, next-header UDP (17) payload length: 56) 2001:9b1:c395:d000:e51:1ff:fee2:88b4.65485 > 2a01:b740:a08:4000::1f2.123: [udp sum ok] NTPv3, length 48
    82.196.108.106.19893 > 194.58.206.148.123: NTPv4, length 48
    194.58.206.148.123 > 82.196.108.106.19893: NTPv4, length 48
09:57:25.333826 IP6 (flowlabel 0x47b58, hlim 63, next-header UDP (17) payload length: 56) 2001:9b1:c395:d000:e51:1ff:fee2:88b4.65484 > 2a01:b740:a08:3000::1f2.123: [udp sum ok] NTPv3, length 48
    82.196.108.106.123 > 194.58.202.20.123: NTPv4, length 48
    194.58.202.20.123 > 82.196.108.106.123: NTPv4, length 48
    82.196.108.106.16979 > 216.239.35.8.123: NTPv4, length 48
    82.196.108.106.35606 > 216.239.35.0.123: NTPv4, length 48
    216.239.35.8.123 > 82.196.108.106.16979: NTPv4, length 48
    216.239.35.0.123 > 82.196.108.106.35606: NTPv4, length 48
    82.196.108.106.42605 > 216.239.35.4.123: NTPv4, length 48

root@OPNsense:~ # ifconfig igb0
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   description: WAN (wan)
   options=48520b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NOMAP>
   ether 00:0d:b9:50:53:68
   inet 82.196.108.106 netmask 0xffffffc0 broadcast 82.196.108.127
   inet6 fe80::20d:b9ff:fe50:5368%igb0 prefixlen 64 scopeid 0x1
   inet6 2001:9b1:10d:39::1:bed3 prefixlen 128
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

And this is just from ordinary running system. No restart of NTP service

[gunnarf]

Could you do that with -n and show an ifconfig output of your WAN interface and the netstat -rn output?

Here is my second firewall. Clearly no respons from the ipv6 NTP servers. And also the "bad udp cksum"!

10:10:35.177188 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) 2001:9b0:40::967c:56c9.123 > 2606:4700:f1::1.123: [bad udp cksum 0x8578 -> 0x089e!] NTPv4, length 48
10:10:38.170181 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) 2001:9b0:40::967c:56c9.123 > 2003:a:87f:c37c::1.123: [bad udp cksum 0x038a -> 0xa30b!] NTPv4, length 48
10:10:39.122574 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) 2001:9b0:40::967c:56c9.123 > 2a00:d78:0:712:94:198:159:10.123: [bad udp cksum 0x599f -> 0xf7bb!] NTPv4, length 48
    46.59.40.76.123 > 91.209.0.19.123: NTPv4, length 48
    91.209.0.19.123 > 46.59.40.76.123: NTPv4, length 48

and ifconfig from that box
root@OPNsense:~ # ifconfig igb0
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   description: WAN (wan)
   options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
   ether 00:0d:b9:51:6d:a8
   inet 46.59.40.76 netmask 0xffffff00 broadcast 46.59.40.255
   inet6 fe80::20d:b9ff:fe51:6da8%igb0 prefixlen 64 scopeid 0x1
   inet6 2001:9b0:40::967c:56c9 prefixlen 128
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

[Patrick M. Hausen]

The "bad checksum" can be an artifact of tcpdump itself. But it might be worth a try to disable hardware offloading for that interface.

Also what does ntpdate -q for these servers result in? Also no answer at all?

And last - is this OPNsense a hosted service or is "Bahnhof" the company responsible for the OPNsense? If hosted, is it remotely possibly they are blocking NTP? It could be abused for amplification attacks and many providers used to do this.

[gunnarf]

The "bad checksum" can be an artifact of tcpdump itself. But it might be worth a try to disable hardware offloading for that interface.

Also what does ntpdate -q for these servers result in? Also no answer at all?

And last - is this OPNsense a hosted service or is "Bahnhof" the company responsible for the OPNsense? If hosted, is it remotely possibly they are blocking NTP? It could be abused for amplification attacks and many providers used to do this.

The OPNsense fw's are mine. Bahnhof is my isp for both.

output from ntpdate -q on the said servers:

root@OPNsense:~ # ntpq -pnw
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*91.209.0.19     194.58.204.148   2 u   60   64  377   13.413   -5.595   0.304
+194.58.205.20   .PPS.            1 u   59   64  377    7.151   -5.286   0.329
2606:4700:f1::1 .INIT.          16 u    -  512    0    0.000   +0.000   0.000
2003:a:87f:c37c::1
                 .INIT.          16 u    -  512    0    0.000   +0.000   0.000
2a00:d78:0:712:94:198:159:10
                 .INIT.          16 u    -  512    0    0.000   +0.000   0.000
root@OPNsense:~ # ntpdate -q 2606:4700:f1::1
server 2606:4700:f1::1, stratum 3, offset -0.005963, delay 0.02797
19 Jul 10:35:44 ntpdate[6654]: adjust time server 2606:4700:f1::1 offset -0.005963 sec

root@OPNsense:~ # ntpdate -q 2003:a:87f:c37c::1
server 2003:a:87f:c37c::1, stratum 2, offset -0.007790, delay 0.05881
19 Jul 10:36:03 ntpdate[64091]: adjust time server 2003:a:87f:c37c::1 offset -0.007790 sec

root@OPNsense:~ # ntpdate -q 2a00:d78:0:712:94:198:159:10
server 2a00:d78:0:712:94:198:159:10, stratum 1, offset -0.007000, delay 0.05038
19 Jul 10:36:23 ntpdate[30047]: adjust time server 2a00:d78:0:712:94:198:159:10 offset -0.007000 sec

[Patrick M. Hausen]

So ntpdate works but ntpd doesn't? WTF?

Ah ... one moment.

Are you running ntpdate -q as root? Can you verify with tcpdump that it is also using port 123 as the source port? If it doesn't, then that might hint at your ISP or somebody else blocking port 123 for IPv6.

Also, did you try disabling hardware offloading?

[gunnarf]

So ntpdate works but ntpd doesn't? WTF?

Ah ... one moment.

Are you running ntpdate -q as root? Can you verify with tcpdump that it is also using port 123 as the source port? If it doesn't, then that might hint at your ISP or somebody else blocking port 123 for IPv6.

Also, did you try disabling hardware offloading?

I don't know where to disable hardware offloading.

The login is as root, so Yes I'm running not-date -q as root

I'm waiting for my ISP to answer me on chat whether they are blocking 123 for ipv6 for some reason

[Patrick M. Hausen]

See screenshot.

[gunnarf]

Thanks. Do I have to restart the fw for these settings to be disabled?

I rebooted the fw. will check after

[gunnarf]

After reboot the only difference is that in the status window for NTP it says .STEP. instead of .INIT. But still no contact

[gunnarf]

The only difference from before is that now the cksum says OK

    46.59.40.76.34685 > 203.107.6.88.123: NTPv4, length 48
    203.107.6.88.123 > 46.59.40.76.34685: NTPv4, length 48
11:26:47.165656 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) 2001:9b0:40::967c:56c9.123 > 2003:a:87f:c37c::4.123: [udp sum ok] NTPv4, length 48
11:26:59.193757 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) 2001:9b0:40::967c:56c9.123 > 2001:440:1880:7373::2.123: [udp sum ok] NTPv4, length 48
11:27:04.182473 IP6 (class 0xb8, hlim 64, next-header UDP (17) payload length: 56) 2001:9b0:40::967c:56c9.123 > 2a00:d78:0:712:94:198:159:10.123: [udp sum ok] NTPv4, length 48
    46.59.40.76.123 > 194.58.207.20.123: NTPv4, length 48
    194.58.207.20.123 > 46.59.40.76.123: NTPv4, length 48

[Patrick M. Hausen]

Next step: your ISP.

[gunnarf]

I had a chat with the ISP. They are not blocking port 123

[Patrick M. Hausen]

So possibly the NTP server in question does not like your source network? Definitely running out of ideas, now.

You could try the public NTP servers of Physikalisch-Technische Bundesanstalt, the official time source of Germany. They are open to the public, their only request is that one only points firewalls and other central systems at them and not each and every single desktop system.

ptbtime1.ptb.de: 2001:638:610:be01::108, 192.53.103.108
ptbtime2.ptb.de: 2001:638:610:be01::104, 192.53.103.104
ptbtime3.ptb.de: 2001:638:610:be01::103, 192.53.103.103
ptbtime4.ptb.de: 2001:638:610:cecf::7b, 194.94.95.123