NTP set to time.google.com not working after reboot
-
Enabling IPv6 in | System | Advanced | Networking | made no difference.
I forward all my DNS request to my two Pi-Hole servers. I wounder if that could be causing the problem. I'll try 1.1.1.1 and see if that helps.
Roy...
-
That didn't help!
Roy...
-
The only configuration I can get to work immediately after a reboot is:
216.239.35.12 set to Pool.
Roy...
-
I guess for now I'm going with this:
216.239.35.0 - Server
216.239.35.4 - Server
216.239.35.8 - Server
216.239.35.12 - ServerI should be OK as long as Google sticks with those addresses.
Roy...
-
@rpsmith said in NTP set to time.google.com not working after reboot:
I have "Allow IPv6" unchecked.
well that would actively block all IPv6 - even if pfsense had a ipv6 address your not going anywhere..
-
It didn't matter whether is was allowed or not it still didn't work. Why does pfSense prefer IPv6 by default or does it?
Roy...
-
Got this from Grok3:
"Google supports IPv6, and time.google.com may return an AAAA record like the one above. Google only serves AAAA records to clients with good IPv6 connectivity to optimize performance."
So is there anything pfSense can do to stop google's DNS servers from giving out IPv6 addresses instead of IPv4? My firewall only have IPv4 addresses on the WAN.
Also, why does it resolve properly when I restart the NTP service?
Roy...
-
@rpsmith said in NTP set to time.google.com not working after reboot:
Google only serves AAAA records to clients with good IPv6 connectivity to optimize performance.
that is highly unlikely.. AAAA is returned even over IPv4 - I get answers and I sure am not talking to them via IPv6 when I do my query to 8.8.8.8 for dns, etc..
The services prob drops over to IPv4 then.. I would suggest you prefer IPv4 down near the bottom of the ntp settings page.
All things that have IPv6 try and prefer IPv6 over IPv4 if they have a valid address. I would be really curious do you actually have IPv6? when you allow it via that checkbox.. Try and ping say at
time1.google.com. 3600 IN AAAA 2001:4860:4806::
[24.11-RELEASE][admin@sg4860.home.arpa]/: ping 2001:4860:4806:: PING(56=40+8+8 bytes) 2001:470:1f10:2f6::2 --> 2001:4860:4806:: 16 bytes from 2001:4860:4806::, icmp_seq=0 hlim=119 time=8.586 ms 16 bytes from 2001:4860:4806::, icmp_seq=1 hlim=119 time=8.419 ms 16 bytes from 2001:4860:4806::, icmp_seq=2 hlim=119 time=8.737 ms 16 bytes from 2001:4860:4806::, icmp_seq=3 hlim=119 time=9.745 msIf you have no IPv6 address, and don't want anything to get a AAAA response almost anything will ask for both A and AAAA when you lookup something, even if it doesn't have an IPv6 address - yeah its stupid if you ask me, but that is not a pfsense/freebsd thing - that is just a stupid shortcut OSes and applications take..
You can set unbound not to use IPv6 and not to return IPv6 addresses..
firefox is horrible with doing that. but you can disable it in firefox for example with
-
I tried setting the NTP service to IPv4 but that made no difference. Also my WAN interface is set to IP configuration type set to None.
This smells like a BSD or pfSense bug to me but I'm not a programmer.
Roy...
-
I thought KEA didn’t like domain names in NTP
-
I'm not using KEA and it works flawlessly when I restart the NTP service.
Last time I tried switching to KEA it stop renewing leases and I had to scramble to reset a bunch of firewalls to stop using it. I'm not impressed.
Roy...
-
@rpsmith kea would have zero to do with dns or ntp - ZERO!!!
See my edit above about setting ntp to prefer IPv4 dns, and also how to stop unbound using IPv6 or trying and or answering a client that asks for a AAAA
Kea doesn't like fqdn for ntp that you would hand to your clients.. Because per RFC setting a ntp server in dhcp is an IP only thing.. ISC and pfsense just resolves it before handing it out via a dhcp lease to some client. maybe kea in the furture or current iteration on pfsense does that now - but its bad to let clients people think you can put in fqdn for ntp server to hand to clients - because the dhcp that is not borked isn't going to do that.. The rfc clearly states IP for ntp servers. That pfsense ever allowed the option in the first place was a mistake if you ask me.
-
I'm not using unbound. I'm using forwarder to forward DNS lockups to my two pi-holes.
Roy...
-
@rpsmith unbound can forward.. Do you have pfsense asking loopback 127.0.0.1 or ::1 which would be service running on pfsense.
You can for sure do the same setting in pihole, because unbound can be used on pihole. You can prob look in pihole on how else to not return AAAA for clients that ask, but almost all clients will ask for both AAAA and A when looking up something.
But if you have no IPv6 and ntp/pfsense thinks it should talk to something via IPv6 since it got back an AAAA back - then yeah your prob not going to have a good day.
-
@johnpoz said in NTP set to time.google.com not working after reboot:
kea would have zero to do with dns or ntp - ZERO!!!
Release note suggest there is an interaction
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.htmlDHCP (IPv4)
Fixed: Kea does not allow FQDNs for NTP servers but input validation does not prevent them from being added #14991 -
@Patch said in NTP set to time.google.com not working after reboot:
@johnpoz said in NTP set to time.google.com not working after reboot:
kea would have zero to do with dns or ntp - ZERO!!!
Release note suggest there is an interaction
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.htmlDHCP (IPv4)
Fixed: Kea does not allow FQDNs for NTP servers but input validation does not prevent them from being added #14991The release note, and the associated diffs, indicate that the UI incorrectly allowed giving Kea a DNS name instead of an IP address. Kea, and the DHCP protocol, require an IP address. ISC apparently would take the DNS name and resolved it for you, but Kea will not.
-
The details are beyond me but this post suggests significant interaction occurs and will increase https://forum.netgate.com/post/1214629
-
@Patch said in NTP set to time.google.com not working after reboot:
The details are beyond me but this post suggests significant interaction occurs and will increase https://forum.netgate.com/post/1214629
That’s about DHCP client registration and resolution. Not related to this NTP issue.
-
Try setting
Prefer IPv4 over IPv6in Sys > Adv > Networking. -
The big question is here - will ntp do a A and AAAA query or not.. If you can stop it from asking for AAAA or stop what it asks for dns - in this case his pihole from answering AAAA..
Any of those options and the problem of ntp trying to talk to an address it clearly can not goes away.
This is why the whole clients asking for A and AAAA is problematic - yes in a perfect world everyone would have IPv6 and be using that, and the A stuff would only be there to support sites that do not have IPv6 yet..
My problem is with any sort of dns client even asking for AAAA (ipv6) address of something if has no viable gua IPv6 to talk to it worth - its pointless to ask for something you can not use - its added traffic, overhead and leads to weird stuff like this.
I am not exactly sure what that prefer IPv4 in ntp services actually mean - that might just mean hey only ask IPv4 dns - but it still asks for AAAA?
What I would hope it means is not ask for AAAA for ntp servers your trying to resolve. Problem solved.. If that is not the case than having your dns resolver or forwarder not answer AAAA back to the client, again problem solved.
I know dnsmasq has a filter-aaaa that should work, I know unbound has the options I showed above that will stop it. And know bind has an option of filtering AAAA as well..
So to me the best solution when you do not have a viable IPv6 address is to just stop the name server your asking from answering any AAAA query.. Now best option would to stop the client from asking - but that might not always be possible.
I will try and sniff with those options set in ntp and see if it stops AAAA query - I suspect maybe not. And just uses IPv4 to ask whatever nameserver the OS its running on is pointed too.
