NTP server pools can't be resolved [Solved, 2 problems in 1 post]
-
@Gertjan said in NTP server pools can't be resolved:
When you use the Resolver as a Resolver, it should be able to find "at leats one of the 13". I presume you do not host locally one of these main Internet Root servers ;)
What?! That was my logic exactly back then when we talked before about VPNs and DNS etc. I remember you told me YOU yourself use "Localhost" and I should do too because using a VPN interface would fail to resolve after a reboot because it wouldn't be able to start without someone else to resolve it first (when used with FQDN instead of IP).
Regardless of these settings, pfsense should still cahce results and search in locally (127.0.0.1) first right?
-
@techtester-m said in NTP server pools can't be resolved:
I remember you told me YOU yourself use "Localhost" and I should do too because using a VPN interface would fail to resolve after a reboot because it wouldn't be able to start without someone else to resolve it first (when used with FQDN instead of IP).
Interesting. Where was it ?
The unbound config command : https://nlnetlabs.nl/documentation/unbound/unbound.conf/ - look at that page the explanation of this setting "outgoing-interface" setting.
When a DNS request comes in, an answer will be send back if the resolver/unbound cache contains a valid (already recorded) answer. If not, and the request isn't using a local zone, the request will get forwarded or resolved up stream
These are my words, but I strongly advise you to read the official ones, now you know where the unbound doc is ;)
nlnetlabs.nl are the authors of unbound, which is used "as is" by pfSense.Images above :
You activated DNSSEC while using Forwarding mode : not an issue, but useless. DNSSEC, as you should know, has no meaning while forwarding.You have "DHCP Registration" activated. That can have consequences - see the hundreds of other posts related that that specific subject. Do as you wish. Just understand why you should, or shouldn't.
This is the are, probably only setting in pfSense that I would change from it's default value.Firewall rule :
Your second rule with a destibnation of "127.0.0.1" is not possible. An address like 127.0.0.1 is only possible "in" the router/firewall itself, and can not come into an physical interface like "LAN". The Sates counters will stay at 0/0 for an eternity == rule did not apply.ntp servers :
Take the two letter code of your country - and create an URL like :
and done with NTP.
-
@Gertjan said in NTP server pools can't be resolved:
When you are "forwarding", DNSSEC is out.
No not really true - when you forward to a resolver that does dnssec is automatically done for you.. You do not have to tell your local forwarder to ask for it..
Have been over this multiple multiple times.. There is zero reason to ask for dnssec when forwarding.. Where your forwarding either does it or it doesn't.
If your forwarding to a resolver over dot, and it does dnssec - then it would do dnssec, be it you using dot or doh or not.. dnssec is a setting on a resolver, be it you running your own locally, or forwarding to one.
-
@Gertjan said in NTP server pools can't be resolved:
You have "DHCP Registration" activated. That can have consequences
Yeah, I have no idea why I kept that from back then when I was experimenting pfsense. I don't care whatsoever about random dynamic DHCP leases. Only statics and OpenVPN. Thanks for pointing that out :)
@Gertjan said in NTP server pools can't be resolved:
Your second rule with a destibnation of "127.0.0.1" is not possible
Well...this is not my rule. It was auto created by pfsense after I added port forwarding for LAN net to force all DNS (53) to be answered by what is set on pfsense. Could you rethink that or explain me better?
-
Thanks for the heads up.
The word "out" is to short for something that needs to be repeated every week or so .... ;) (and is repeated every week, or so)
8.8.8.8 and other, who are actually resolvers, do support DNSSEC on their "request" side. It's the link between our forwarder (pfSense) and them that somewhat breaks the DNSSEC concept. If that link is over TLS (DoT) then you're sure the info isn't tempered with : you're sure it comes from 8.8.8.8.
But the DNSSEC RFC does not state that some one should trust 8.8.8.8
To see what DNSSEC does, cehckout https://dnsviz.net/d/test-domaine.fr/dnssec/ - all the mine (pointers) between all the circles are checked and verified.
Their is a yet another root concept : the "20326" trusted root key at the top. This key is build in and checked upon each unbound startup. based on this key, all other keys on a lower level are signed => trusted. -
@Gertjan Just changed dns resolver ONI from localhost to all. Set 8.8.8.8 and 9.9.9.9 under general settings, restarted unbound, reset states....still same result. No resolving.
Edit: perhaps my ISP blocking them (on port 53)? And if so why would the stupid ISP block completely and not simply give its own answer and just resolve the request?
-
@techtester-m said in NTP server pools can't be resolved:
perhaps
We asking yourself these questions ?
You have a "pfSense", he'll tell you, just put it to work.Console / SSH (true, the click click show stops, so the real power can be deployed) ;
dig duckduckgo.com +traceand admire the result.
I'm seeing :
. 79203 IN NS c.root-servers.net. . 79203 IN NS h.root-servers.net. . 79203 IN NS k.root-servers.net. . 79203 IN NS d.root-servers.net. . 79203 IN NS g.root-servers.net. . 79203 IN NS b.root-servers.net. . 79203 IN NS m.root-servers.net. . 79203 IN NS e.root-servers.net. . 79203 IN NS l.root-servers.net. . 79203 IN NS a.root-servers.net. . 79203 IN NS i.root-servers.net. . 79203 IN NS j.root-servers.net. . 79203 IN NS f.root-servers.net. . 79203 IN RRSIG NS 8 0 518400 20200709050000 20200626040000 48903 . T12wT/714x73vuIWxAMaZaA4j0D6Pamf3VOICYYm17sRHElWtXf29Xsa raslWtAVqjHBJHpErqlZD3Qq3fd6hboj9Xbri8Ik/irTa78m9zYwO7kW s6BrYUloEzzYDL0eZi8O4gv7CKlnr8mfGrjYkLtUUTheUguxdeuOi/Nv pEpqoJPg0qLEf4jaBocexyi0hmCjRk5sGisQJ1oUTYu32PwrEtHJ2NOw WGnBxjbRW1uR0RNqFZXJ9D2NelTNym9t4LMu1+ENC2l+bq9PoWBSdYke sat/USsbKC5QlMeGYPUodvcJiGvpqTYgFQYjpxTOS0K8s/CoUUcRVFBS 6uqveg== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20200709050000 20200626040000 48903 . mRy6ZWw24zU61QmFBnFUULJe9md6RKkgIF4uuu78rbn9nD/mUBvAOOxM bJWR4wTbck5sCYmLynXCkaxcAXkMvhC6dVJDlmWP1u4SnaBTJzZWN+t+ wWzHCervVDyY4ileHiyn5sVFj87OasQ5vo4uupME463cJ9TCETs/or8o 8bkhD3nezxbixiZVWw0m43W6z2IACBETUR7BlSdCe9VZ3lk5/HdXMVnT Y198/Ranjg/DfM4oacZhfjexYHHlPFl1bgRQ5UDtvddHpIlCFG8s21aV Rff7ftX9eB2MywOH2ewFWg3gtqsVtp21eE5ZqknHOgQAsIoeBqsn8vnR DTPVQQ== ;; Received 1174 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 97 ms duckduckgo.com. 172800 IN NS dns1.p05.nsone.net. duckduckgo.com. 172800 IN NS dns2.p05.nsone.net. duckduckgo.com. 172800 IN NS dns3.p05.nsone.net. duckduckgo.com. 172800 IN NS dns4.p05.nsone.net. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200630044218 20200623033218 39844 com. XLLl9R6DyHumuL5DcLJ502J0Q1wgWp3yCHNR3bmyNznc45/NjPgMt82/ LZcr3B8udPvMahuZAGbTLFcD+l5JnGFznFgqIdpKDzhPO0jY1CFVBN81 k4CNg7Z/35vTEv3vO6qKo6uN7tIW5qWnuiOF4NejSK5kU34PG/ZFVTjw jY6szHRtWK2ru0ipvUwBLWzuc67e2EdMQPRGQGyBl8pV4g== BN1FJS0UO0RMBT477B345GNU6A9CFODA.com. 86400 IN NSEC3 1 1 0 - BN1FSPPU7UST4HCP0ADMG9U117OMTH0V NS DS RRSIG BN1FJS0UO0RMBT477B345GNU6A9CFODA.com. 86400 IN RRSIG NSEC3 8 2 86400 20200701054124 20200624043124 39844 com. eU7OSt9NYB7el3Bqfar0o6Pz1WOpW9aHciC98kqfj0fDjGhnlNKq55wP A4uyXkFfADKvrKgcABbF3Be3gBK1RRdLlDzypXJKiFlhmhTo53R2pwam bJcRyZKODyx+0QOsRqO5QXwZ85dW8Xm6Lj7wccgFacSJVKCSmVS/hnnh Qy4xvm/t0ENOmFtT82pABN0DicsWanRCbcVf04faHIdAKQ== ;; Received 681 bytes from 2001:501:b1f9::30#53(m.gtld-servers.net) in 115 ms duckduckgo.com. 200 IN A 40.114.177.156 ;; Received 59 bytes from 198.51.45.69#53(dns4.p05.nsone.net) in 37 msClearly, you can see that the list with "13" is used.
Alraedy cached was the fact who handles dot com - so .com is questionned.
"j.root-servers.net" = number 10 answered, and gave the domain name servres that handle the domain duckduckgo.com : dnsx.p05.nsone.net (where x is 1 to 5).
Finally, dns4.p05.nsone.net gave the answer - just for me : 40.114.177.156The other lines are DNSSEC related, not really readable for humans.
Btw : You do not have the usual "WAN" interface but a list of VPN connections.
These are just perfect to introduce DNS related issues.What about deleting (de activate) them all, just use a WAN - and do your tests.
Then add just one (1 !) VPN, and re test extensively. The moment things go wrong, will be the moment you know what to correct / do better. -
@Gertjan
This is my result (same as yours only different NS gave the answer):duckduckgo.com. 200 IN A 40.114.177.156 ;; Received 59 bytes from 198.51.44.5#53(dns1.p05.nsone.net) in 60 msWhat now? I still can't use any DNS server other than cloudflare
Edit: Just disabled forwarding mode, rebooted pfsense (just to be sure) and still the same behavior with NTP, in addition to the still existing problem of not being able to forward to Google. So...the conclusion would be that it has something to do with my ISP or something else other than pfsense? I'm lost here...
-
@techtester-m said in NTP server pools can't be resolved:
What now?
At least you know - we actually knew already - that DNS is working.
You browser said that it couldn't connect to duckduck - which implies it has the correct IP (a domain name doesn't mean anything to a browser) but the traffic send from the device on which your browser runs to "40.114.177.156" isn't possible.
I suspect some/most/all your VPN settings. See my comments above. -
@Gertjan I think you're wrong here.
I disabled the policy routing rule with the VPN and sent all LAN traffic through the default gateway which is the WAN.
Disabled the NO_WAN_EGRESS rule in under floating. Changed to 8.8.8.8 under general settings and still...nothing.Also, why would the VPN or any other setting in pfsense care who I'm forwarding the DNS requests? WTH would it work perfectly with Cloudflare but not with others?
Btw, NTP issue still exists even when using "pure resolver" mode without forwarding. I won't reach them and will have just this address 162.159.200.123 as the only Active Peer. Never had such a weird issue before....please help lol
-
As you might know, we do not have the helpdesk tools to guide you from a known, working situation, to drill down to the source of an issue, or even a collection of issues.
What work fast - and would work for you now, is creating a known point of start.
Save your config.
Reset the entire pfSense : option 4 in the console menu.
From this point : you do 5 things :
Assign a WAN interface - by suing DHCP
Assign a LAN interface - and do leave everything to default.
Assign a password to pfSense (and yes, assign logic things like the correct time zone).
Hook up a PC to the LAN. You should have a normal Internet access. Everything should be fine.
// END //
Check this setup as long as possible because any issue on this point is pretty sure located "upstream".
Try everything that didn't work before.
Because: You an I use the same code. And you did not - or very minimalistic, change the default settings. The very same settings "that work for everybody".While doing so, assign a NTP pool - or use the default pool. "Time" should work. Again, if not, issues are upstream.
During the test : do not add/change firewall rules, VPN's, other interfaces or whatever. No DNS changes : nothing.
No 8.8.8.8 or anybody else.
Just the default stuff.You can always go back to the situation you have now, by importing your saved backup, and reboot.
So my test has no risks. -
@Gertjan I'll try and report back after the weekend :) thanks
-
@techtester-m said in NTP server pools can't be resolved:
perhaps my ISP blocking them (on port 53)?
Why not just do a query yourself and check? nslookup, dig, host - your fav dns tool and query whatever NS you want and see if you get an answer..
This is way to "test" if your isp is blocking 53..
example.
C:\>dig @8.8.8.8 www.netgate.com ; <<>> DiG 9.16.4 <<>> @8.8.8.8 www.netgate.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7806 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.netgate.com. IN A ;; ANSWER SECTION: www.netgate.com. 3195 IN A 208.123.73.73 ;; Query time: 25 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jun 26 16:16:35 Central Daylight Time 2020 ;; MSG SIZE rcvd: 60If your wanting to check if your being redirected.. This would be a good simple test.. If directly query any of these they should return your public IP.. If its not your IP, then your dns is being redirected most likely
nslookup whoami.akamai.net. ns1-1.akamaitech.net. nslookup -q=TXT o-o.myaddr.l.google.com. ns2.google.com. nslookup myip.opendns.com. resolver1.opendns.com.Example
$ nslookup whoami.akamai.net. ns1-1.akamaitech.net Server: UnKnown Address: 193.108.88.1 Name: whoami.akamai.net Address: 64.53.x.xThat IP is my actual WAN IP.. where I did the query from - if you get something else back.. Most likely your dns is being redirected.
-
@johnpoz I had the same result as yours. It showed my WAN IP. Still...same problem. But I think I found out what caused it.
-
@techtester-m said in NTP server pools can't be resolved:
It showed my WAN IP. Still...same problem
Very good news.
No ISP issues. Your issues are 'local'. -
@Gertjan I factory reset the settings. Defined everything from scratch one by one and I think I found out the problem which I find weird as well. Perhaps a bug with pfSense, by design or simply something with how DNS servers work.
So...it goes like this: The problem seem to originate from the monitoring IPs set for the gateways. When I use DNS servers as the monitoring IPs of my gateways (especially the WAN I think) I can't use them under General Settings or else it will cause some weird problems that don't make much sense (at least to me). Please check the screenshot below:
-
Monitoring a gateway by using 1.1.1.1 or 8.8.8.8 is a bad idea.
As any server, these (8.8.8.8 - 1.1.1.1 etc) have to protect themselves. There are many Internet users out there with completely hosed (router) network setups, and the firewall of 8.8.8.8 is very capable of blocking IP's that over rate DNS requests, ICMP requests etc. And they probably slam down a /24 so you and your /24 WAN fellows will get blocked - only ICMP or even everything : DNS. These people will notice this, contact their ISP, who contacts 8.8.8.8 who will say : disconnect the ab-user, and we will remove the restrictions. So the ISP will do some network sniffing, find their abusing client and ask him friendly to stop what he is doing ....
This is just an example - and not a invented story : these things happen.
=> and if 8.8.8.8 doesn't reply to ping - because there is no law that says it has to - your WAN will be taken down to be reset. That's problematic. So : stop biothering 8.8.8.8 - it isn't a world wide gateway tester after all.
You be better of using a 'gateway' test IP, more close, one of your ISP.
-
@Gertjan said in NTP server pools can't be resolved:
As any server, these (8.8.8.8 - 1.1.1.1 etc) have to protect themselves...
Goddamn I had a feeling it was something with the DNS servers limiting me. But on the other hand, I only went this path because when I didn't use any IP to monitor the default was the ip of the interface itself which caused some problems in the occasions where VPN gateways were assigned with the same ip.
So you're saying the best approach would be to monitor an IP on the "outside world" but not a DNS one and preferably one within the boundaries of my WAN/ISP? Did I understand you correctly?
Edit: What IPs or servers won't protect themselves or restrict in the same way? Because you would imagine that DNS servers can "take everything you through on them"...kind of lol
-
@techtester-m said in NTP server pools can't be resolved:
best approach would be to monitor an IP on the "outside world"
Who said that? I personally think that is a bad idea.. Unless you have specific reason that, like your ISP gateway doesn't answer or pfsense is actually behind a nat or something..
Best approach is to leave it at default which is to monitor your actual gateway, unless you have specific need/reason to change it.
Why do you have so many freaking vpn connections btw? What I would suggest you get stuff working like dns fowarding and ntp before you start sending all your traffic to some vpn service(s)...
-
@techtester-m said in NTP server pools can't be resolved:
So you're saying the best approach would be to monitor an IP on the "outside world" but not a DNS one and preferably one within the boundaries of my WAN/ISP? Did I understand you correctly?
@techtester-m said in NTP server pools can't be resolved:
What IPs or servers won't protect themselves or restrict in the same way? Because you would imagine that DNS servers can "take everything you through on them"...kind of lol
You got it.
If "people" would know the consequence of their choices, they wouldn't throw in these '8.8.8.8' everywhere.
Better : pfSense monitors the (a) WAN interface. But you don't have to leave it "on" or accept the IP it uses for the test. Although : pfSense never puts in 8.8.8.8 by default : they (Netgate) would receive a phone call from Google to make that stop.
The default DHCP on WAN just pings the upstream gateway, often your your upstream (ISP) router.Myself : I use one of my own dedicated servers on the Internet Its me bothering myself with my own pings. Main advantage : I can trust my own server ^^
