NTP server pools can't be resolved [Solved, 2 problems in 1 post]
-
@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 ^^
-
@johnpoz said in NTP server pools can't be resolved:
Who said that? I personally think that is a bad idea..
Ok...you and @Gertjan seem to disagree on this matter.
@johnpoz said in NTP server pools can't be resolved:
Why do you have so many freaking vpn connections btw?
We've discussed this few months - a year ago. Multiple reasons, which I don't expect everybody to agree on obviously, like: "Stick it to the man", load balancing, failover, OCD etc... :)
@johnpoz said in NTP server pools can't be resolved:
Best approach is to leave it at default which is to monitor your actual gateway
Yeah, I understand that about the WAN gateway. It should ping the upstream gateway because if that won't answer back then there's no point to even try to get to anything beyond that. That being said, when it comes to a 'local' gateway with a virtual ip/one that was set by a VPN server, pinging itself doesn't make sense to me because it's not even the upstream gateway/server ip. It's actually literally pinging itself regardless of internet connection status.
If I'm missing the way gateway monitoring behaves, please bear with me and elaborate more. Thank you.@johnpoz said in NTP server pools can't be resolved:
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)...
That's exactly what I did after I did reset to factory defaults. DNS forwarding is fine when I'm not monitoring gateways using DNS servers as I explained above (found the issue of DNS already). About NTP - even with the default settings of pfsense, it still shows 0 under the 'Reach' column of the NTP pools and chooses the same address as before to be the Active Peer. Unless this is the expected behavior, then it's an ISP behavior.
@Gertjan said in NTP server pools can't be resolved:
Myself : I use one of my own dedicated servers on the Internet
Haha good idea. But... (1) What would you do in case of multiple gateways? pfsense forces you to choose a different monitoring IP for each gateway. (2) Untill I'll setup my own cloud server or something like that, should I just leave it as default and let the VPN gateways to monitor their own internal/virtual interface IPs?
Thank you guys for all the input and knowledge. A little bit more and we'll have an agreeable working solution and I'll have my peace of mind. Please bear with me a little more.
-
This :
@techtester-m said in NTP server pools can't be resolved:
Ok...you and @Gertjan seem to disagree on this matter.
@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?
Let's chop it into pieces :
boundaries of my WAN/ISP?
The closer the better, so why not. Your upstream home ISP router is choses by default if you use DHCP.
but not a DNS one
a DNS servers exists to reply on DNS requests - who knows what it can do with ICMP requests if it gets overloaded ? (or see above for other events)
"outside world"
because the "inside world" = an IP on LAN wouldn't make any sense ;))
So yes, nothing wrong with your phrase.
@johnpoz read / understood something else ?
Or understood what I missed ... -
@techtester-m said in NTP server pools can't be resolved:
it still shows 0 under the 'Reach' column of the NTP pools and chooses
You mean this 0
That is expected for the "pool placeholder"
As to which active peer gets picked, that would the peer that ntp determines is the best one..
Only thing you should be concerned with is that there is an active peer, and that the ntp servers your trying to talk to show reaches as 377, this means that that server has answered the last 8 times in a row talking to it.
If you want have pfsense only talk to or pick from the ntp servers you want, then pool is not for you.. specifically list only the ntp servers you want ntp to use.. Any pool is going to be a randomly changing list of servers that are in the "pool"..
-
@johnpoz said in NTP server pools can't be resolved:
That is expected for the "pool placeholder"
Thank you, that's what I wanted to know. So in that regard everything is working perfectly.
@johnpoz said in NTP server pools can't be resolved:
that the ntp servers your trying to talk to show reaches as 377
That's ok too. I see this exact number in the Active Peer row (Reach column).
@johnpoz said in NTP server pools can't be resolved:
If you want have pfsense only talk to or pick from the ntp servers you want, then pool is not for you
I do want a pool but it seems it picks the wrong server (or maybe not...). Let me explain the issue: I use a Ubiquiti EdgeSwitch and I've noticed a wrong date (Jan xx, 2020) when I downloaded the config file and opened it. So I set my pfsense address as the SNTP server (EdgeSwitch settings) for that switch. Downloaded the config file again and noticed an almost correct date (Jun xx, 2020) but with the UTC (+8) of somewhere in the east cost of the US or Canada I think. Checked the address of the Active Peer (always the same one) in pfsense and searched it with iplocation.net. I received multiple results (screenshot below):
-
@Gertjan said in NTP server pools can't be resolved:
The closer the better, so why not. Your upstream home ISP router is choses by default if you use DHCP.
I understand, thank you. What about a VPN gateway with the address of 10.x.x.x assigned by the VPN server? pfSense will monitor this exact IP. Seems a bit different to me from monitoring the WAN IP idk why...feels wrong, unless I misunderstood something and it only looks like a local/virtual address but because I'm connected to the VPN server I'm on a sort of a different LAN with that server and therefore that IP would be considered as 'upstream'. Can you explain that a little bit more, please?
@johnpoz Johnny boy you can elaborate on the matter as well lol :) Feel free...
Edit: I visualized and wrote my thesis on the matter (see screenshot below). Can you please tell me if my understanding of how things work is correct?
-
When you use the VPN client on pfSense to connect to a VPN server, it will receive a tunnel IP "on the pfSense side" and there will be an IP on the other side - the VPN server. This one should be able to reply on "ping" and is thus perfect to do the "dpinger ping tunnel "WAN" test".
When the tunnel goes down, dpinger - the task that actually monitors the WAN = VPN interface, will kick around the VPN client by restarting it.All you need is a IP "on the other side".
Even 8.8.8.8 could work for years without issues - for others : it doesn't.
Just use an IP that you can trust a,d/or check because, remember, if that IP can't be reached any more, dpinger will do 'bad' things with that WAN connection. Something that can be disabled if you trust your WAN/VPN/etc connection enough.Btw : I've a VPN connection "to play with" - to see what it is. I'm not actually using it, because I still do not understand why I should need one.
Just one - the setup - messes up my pfSense connection enough - things become over complicated / not transparent at all. When things go bad it's not simple any more to do the basic "debug" steps.
And you use 3 of them ?? -
@Gertjan For the actual WAN I'll use the upstream ISP gateway.
@Gertjan said in NTP server pools can't be resolved:
All you need is a IP "on the other side"
But which is what? Is the 10.x.x.x the tunnel IP (local) and the IP "on the other side" is simply the VPN server address...OR is the 10.x.x.x address is the one "on the other side" but only looks local (but is virtual)? Seems simple but the semantics can be confusing sometimes.
-
@techtester-m said in NTP server pools can't be resolved:
But which is what?
Actually : any IP on the Internet will do.
With the restrictions stated above. -
This post is getting too big lol. I'll ask these and move on. I don't want to waste your time.
*** Deleted last questions ***
Edit: I think this answers all my questions (from Netgate docs) -
For now I'll use the default. If there will be any problems in the future I'll try using the public address of the VPN servers. If that won't help I'll use major websites addresses. And finally if that won't work out as well I'll have to use my own server/cloud/domain etc.
Thank you both guys for all the help. Much appreciated! Cheers! :)
-
Update -
@Gertjan @johnpoz
I think one of the problems (or the main one) was not a DNS blocking/limiting etc. but a static route to it set by pfsense because it was used as a monitoring IP etc. (read about it online). Since I'm never gonna use 4.2.2[1-6] for production DNS resolving, I decided to utilize them as monitor IPs for every gateway that is not the WAN itself or has no proper 'upstream' gateway to check against.Currently I'm happy with the solution below. I think the assumption mentioned in the screenshot is correct but we'll see what happens.
