DNS Resolver doesn't work with my university domain.
-
@johnpoz
I know it doesn't make sense.My guess is this: the bios time is wrong by 4 minutes and the NTP code only fixes the date and hours, leaving minutes and seconds up to the BIOS clock.
Tomorrow I'll take this PC down and check the BIOS. -
@fandangos no not how it works, ntp would take it to the ms to be honest.. You got something weird that is for sure..
But it can take a bit to adjust the time using ntp..
-
ok check this out, I believe my ISP blocks port 123 or it's block NTP access:
So, my BIOS is 4 minutes behind and since Pfsense can't access the NTP servers it just changes the time zone adding or subtracting a few hours.
Now I used to have this problem with a FPGA system that runs linux and I used to solve this by this nice startup script in bash that sadly will not work on pfsense:
RET=-1 while [ ${RET} -ne 0 ] ; do ping -c1 google.com RET=$? sleep 1 done date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"so I've found a small utility on android called Time Server that uses GPS and is able to run a server but on port 1234.
I wasn't able to add the port to the system like 192.168.0.20:1234 but I was able to set 192.168.0.20.
The error is that the : makes it a invalid ipv4 or ipv6 address.I don't see on the system logs anything about a successful NTP sync with the app but now the time is correct.
If I look at/var/etc/ntpd.confIt's like this:
# Upstream Servers server 192.168.0.20 iburst maxpoll 9And now look what works:
[2.6.0-RELEASE][admin@pfSense.home.arpa]/var/log: ping ufscar.br PING ufscar.br (200.136.207.122): 56 data bytes 64 bytes from 200.136.207.122: icmp_seq=0 ttl=55 time=18.258 ms 64 bytes from 200.136.207.122: icmp_seq=1 ttl=55 time=18.267 ms 64 bytes from 200.136.207.122: icmp_seq=2 ttl=55 time=18.256 ms 64 bytes from 200.136.207.122: icmp_seq=3 ttl=55 time=18.279 ms ^C --- ufscar.br ping statistics ---So it's indeed a time sync problem that prevents DNSSEC to work.
Also, changing to America/Sao_Paulo actually set the clock right this time, so, it was fixed in pfsense 2.5.
Now only if there's a way to bypass the port 123 block from my ISP so I could normally use NTP servers because honestly I don't know what exactly fixed the problem.
I also selected all the interfaces under NTP settings but that was it, the android server and selecting all interfaces something fixed it for now. -
I'm not sure what fixed it, really here I believe (not sure) is the moment that the clock was fixed:
maybe it has nothing to do with the android time server, I don't know.
The log doesn't give much info. -
@fandangos said in DNS Resolver doesn't work with my university domain.:
I don't know.
The log doesn't give much info.I know. It looks like that.
But reading and understanding logs needs a learning phase ;)Lines like this :
means that syncing is progress
Hardware that uses an RTC that is some seconds off every day isn't a big deal, but if the hardware RTC can't be set using ntpd, and it start to lag behind a lot, then you have a problem.
Your hardware is nice for a game device, not a router/firewall.If ntp can't set the hardware RTC clock, then on every boot your system clock is lagging behind even more.
ntpd needs time to sync back to the real time.
During this sync time, everything that uses 'time' can be off.
Like DNSSEC. And more.
So, consider :
Not rebooting pfSense ;)
If you reboot, set the time manually (as ntpd can brute force the time, it will go slowly).
And when your done with it : change hardware, with a good RTC.
Do check the battery, if there is one.The exact time is an important resource these days.
This is strange :
as the ntpd should stay in memory 'all the time'.
-
The thing is, it never synced before (I have this pfsense setup for months now) and now it's not syncing again.
If I look at Status / NTP
It's not synchining and I've added several pools to try.
Here's the log for the NTP service trying several servers without any success:
https://pastebin.com/Hqna2gvQ [too big to post here]The lan ip is the android server that is off for now.
I have no idea how it managed to sync that only time but as you can see something (proably my ISP) is blocking it because I see this same problem with windows server, with unraid.. and so on.
-
@fandangos have you contacted your isp about this? Blocking ntp is very detrimental to proper option many things these days. You need actuate time for many things to work correctly.
If they block external ntp - do you they run their own ntp you can sync with, atleast that would be something. How many isp block outbound smtp, but they provide you with a smtp server you can use, etc.
edit: as a work around you could run your own ntp like you were doing off your phone. I run one via a raspberry pi and a gps hat. Total project should cost under $100.
So out of curiosity what is the isp device in front of pfsense, is pfsense IP a rfc1918 address or are you getting a public IP on pfsense wan. It could be possible that maybe the isp device is doing something with ntp, and having issue natting it for clients downstream - like pfsense.
I would suggest you contact your isp about not being able to talk to any ntp servers, see what they say. Its possible you will have to escalate past level 1 support to get to someone that understands what your talking about.
-
@johnpoz
Yeah, I manage quiet well to even not think : "we've seen it all".
But now I say it : "@Fandangos, your ISP is definitely not expensive enough" ;)Not relaying ntp ..... what's next ? Blocking https and pop, why not imap ? No ? Block SSH as it is scary.
Or has 'ntp' been thrown on some s@nction list ? ( You see what I mean ?)
-
I have to give my ISP a call but talking to people inside the tech area is quite difficult.
Today is a not a working day so I can't give it a call.
I'll try tomorrow.And I have no idea if my ISP have a NTP service.
I don't think there's such a thing as retrieved NTP service address like DNS is set by dial up PPPoE, right?
-
@fandangos said in DNS Resolver doesn't work with my university domain.:
people inside the tech area is quite difficult.
Ah, good news then : you're in Europe then ;)
Don't worry. The people who can tell you what's up are not available for the muppets like me and you.
We have another way to express ourselves :
Old ISP => Bye !
New ISP => Hi !
( but first, before you buy, do some fact checking, and don't call them to ask if they feel they are good, ask others )@fandangos said in DNS Resolver doesn't work with my university domain.:
And I have no idea if my ISP have a NTP service.
You don't need them for that.
They 'just' need you to give a connection, and not blocking 'some' stuff.Pick your NTP pool or server from here https://www.ntppool.org/en/, or, why not, keep the default one.
There is only one important setting in pfSense :
This one :
and you can consider to select a pool nearby. But that's optional.
-
That's a 3h offset by my calculation (unless that includes the timezone?) which I could see being an issue for DNSSec. 4m seemed unlikely.
Any sort of local server would be waaay better than 3h! -
I'm located in Brazil.
I've set several NTP servers, none work.
I see this same behavior with several network devices on my lan.I have a FPGA board that doesn't have a RTC and it syncs the time at every boot.
I use the bash script I posted earlier to bypass this.My Unraid NAS have this same problem.
And my windows machine fails with windows ntp server.
And I don't have many ISP options in my area that have this kind of speed I have here, which is 600 mbit down and 300 mbit up so I'll try talking to them.
We have laws in Brazil that prevent port blocking as the law says all onlines services must be provided equally, it's called "marco civil da internet" here.
If they don't open the port by a user request I can sue and force them to do it.Meanwhile a proxy/vpn bypass could be a solution?
Or I'll try to port my bash script to pfsense shell and figure out how to run it with shell and root at startup.
-
@fandangos said in DNS Resolver doesn't work with my university domain.:
Meanwhile a proxy/vpn bypass could be a solution?
You shouldn't have to do that, especially if there is some law in Brazil that says your isp can not be blocking ports. NTP is a very common and required service for proper operation of the internet to be honest. Many things require accurate keeping of time, while you don't have to be plus or minus a couple of ms ;)
So all your devices are behind pfsense that have this problem right? So just to cover your bases before you go yelling at your isp. I would sniff on pfsense wan do you see it sending ntp queries? and just not getting answers?
example.
You can see traffic from my wan IP to ntp server on 123, while I get responses and everything is working great.. Do you just not see any replies but see traffic going out ntp server IP on port 123..
-
I have no idea why 4 minutes broke it for one particular site but I can say with confidence after that breaf sync that happened and it's blocked again dns resolver with dnsssec enabled is resolving my university address.
-
@fandangos I don't think it was the 4 minutes, it was most likely your hours offset compared to your actual timezone.
you can be in timezone X on a system, but have the wrong time for that timezone - but be the correct time for your location as you see it on the clock on the system. But when you have systems doing math to figure out stuff you could have issues.
-
I did a quick capture here looking at the NTP logs:
And the capture:
11:08:25.168577 IP 135.181.21.151.59574 > ***.***.***.***.64050: tcp 1435 11:08:25.172578 IP ***.***.***.***.123 > 162.159.200.1.123: UDP, length 48 11:08:25.180765 IP 135.181.21.151.59574 > ***.***.***.***.64050: tcp 1435 11:08:25.180994 IP 135.181.21.151.59574 > ***.***.***.***.64050: tcp 1435No response.
11:08:31.261478 IP ***.***.***.***.46877 > 31.13.85.23.443: tcp 0 11:08:31.263652 IP ***.***.***.***.123 > 138.36.164.35.123: UDP, length 48 11:08:31.267118 IP 65.21.136.253.59139 > ***.***.***.***.2021: tcp 1435 11:08:31.267160 IP 65.21.136.253.59139 > ***.***.***.***.2021: tcp 1435Nothing here too
11:08:32.264276 IP ***.***.***.***.64050 > 135.181.21.151.59574: tcp 0 11:08:32.265292 IP ***.***.***.***.123 > 162.159.200.123.123: UDP, length 48 11:08:32.265896 IP 135.181.21.151.59574 > ***.***.***.***.64050: tcp 1435 11:08:32.265941 IP 135.181.21.151.59574 > ***.***.***.***.64050: tcp 1435Again, nothing.
I just removed my IP from the capture but that's it, no response.
-
@fandangos you can limit your capture to just udp 123 so you don't see any other traffic..
But yeah if you see it going out, and no response time to call the isp and complain..
edit: if I had to "guess" its quite possible the isp doesn't have a problem with the destination of 123, but they may be blocking because of the source port being 123.. I don't believe you can change this, atleast not in the gui. with official ntpd I don't think you can, but very possible to change I believe with openntpd or chrony which are two other ntp applications.. So if you could run say one of those on some other box you have on network and make sure its not using 123 as the source port.
Notice in mine, the source is not 123 - but that is most likely because that is my ntp server I run on my pi talking to the internet, and it is using ntpsec and not official ntp distribution. And its traffic would be natted by pfsense anyway, which changes the source port anyway. If they were blocking just source 123, and pfsense would change the source port when it nats to your public - that wouldn't explain why they are all having problems. Yeah time to contact the isp..
pi@pi-ntp:~ $ ntpq ntpq> v ntpsec-1.2.1+85-g1a7bb2e3a ntpq>While my ntp server running on my pi does use a gps hat, I still have it talking to other ntp servers on the net as well
ntpq> pe remote refid st t when poll reach delay offset jitter ======================================================================================================= *SHM(1) .PPS. 0 l 15 16 377 0.0000 -0.6251 0.0897 -SHM(0) .GPS. 0 l 23 64 377 0.0000 -163.411 6.8951 -ntp-0.gw.illinois.edu 200.7.224.32 2 u 56 64 377 15.4833 2.3487 1.0280 +ntp.your.org .GPS. 1 u 30 64 377 12.3152 1.6419 1.7052 -tock.usshc.com .WAAS. 1 u 4 64 377 35.3330 10.2600 1.2384 +ntp1.netwrx1.com 127.127.28.0 2 u 11 64 377 27.3171 -6.2840 6.5250 ntpq>ntp via gps can be tricking to get offset worked out, etc. I have it more for the pps signal and get time from other stratum 1 and 2 public ntp servers.
edit2: to be complete in your info you have when you call your isp. Always best to do your due diligence when dealing with them.. I would change your sniff to only capture udp 123, and then run your sniff for a while and make sure you have some traffic coming from other ntp server on your network natting through pfsense so your source is not the 123, and also shows it doesn't get responses either.
-
I have a android time server running here on port 1234.
The problem is that in pfsense gui I can't change the port to 1234, so I can't use it.I also have a unraid box running here, that's a NAS with a modified slackware linux running so I could use that but I believe this is getting way over my head and freeBSD is different enough for me to have a hard time porting that script that checks google.
There's no man, date doesn't take the same arguments and there's no wget.
I tried changing/usr/local/etc/pkg/repos/pfSense.confwith
FreeBSD: { enabled: yes }but
[2.6.0-RELEASE][admin@pfSense.home.arpa]/var/log: pkg install wget Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. pkg: No packages available to install matching 'wget' have been found in the repositoriesBasically this is my workaround on other devices running linux in the house:
date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z" -
@fandangos so you on your sniff you show traffic leaving pfsense where the source is not 123, and they get no answers either. Or did you disable their ntp servers and just use your work around..
Just want you to have as much info as possible when complaining to your isp. A good sniff showing traffic with source port 123 and other with other source port that your not getting any answers to anything that you send to port 123 ntp..
-
not sure if I follow.
I don't know what those TCP packets are. I just pasted those to show that right after the UDP 123 request there's nothing comming back at 123.My workaround uses wget, there's nothing of NTP there, it just gets the date set by google.
Now I've found a docker container on Unraid called NTP that by the description uses chrony:
https://hub.docker.com/r/cturra/ntpinstalled it and used
pool.ntp.org, time.google.comas NTP_SERVERS
Log from this docker container:
2022-09-07T14:43:54Z chronyd version 4.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG) 2022-09-07T14:43:54Z Disabled control of system clock 2022-09-07T14:43:54Z Could not read valid frequency and skew from driftfile /var/lib/chrony/chrony.drift 2022-09-07T14:43:59Z Selected source 143.107.229.210 (pool.ntp.org) 2022-09-07T14:43:59Z System clock wrong by 74.923575 seconds 2022-09-07T14:43:59Z Could not step system clock 2022-09-07T14:44:01Z System clock wrong by 74.923624 secondsSo I set my unraid box as ntp server on pfsense and look at this:
10.27.33.198 is my unraid box.
So... I'm lost, the docker is able to access the NTP pool but Pfsense and unraid itself is not?
Sep 7 11:58:53 Tower root: Stopping NTP daemon... Sep 7 11:58:54 Tower ntpd[1525]: ntpd 4.2.8p15@1.3728-o Fri May 21 19:02:16 UTC 2021 (1): Starting Sep 7 11:58:54 Tower ntpd[1525]: Command line: /usr/sbin/ntpd -g -u ntp:ntp Sep 7 11:58:54 Tower ntpd[1525]: ---------------------------------------------------- Sep 7 11:58:54 Tower ntpd[1525]: ntp-4 is maintained by Network Time Foundation, Sep 7 11:58:54 Tower ntpd[1525]: Inc. (NTF), a non-profit 501(c)(3) public-benefit Sep 7 11:58:54 Tower ntpd[1525]: corporation. Support and training for ntp-4 are Sep 7 11:58:54 Tower ntpd[1525]: available at https://www.nwtime.org/support Sep 7 11:58:54 Tower ntpd[1525]: ---------------------------------------------------- Sep 7 11:58:54 Tower ntpd[1527]: proto: precision = 0.043 usec (-24) Sep 7 11:58:54 Tower ntpd[1527]: basedate set to 2021-05-09 Sep 7 11:58:54 Tower ntpd[1527]: gps base set to 2021-05-09 (week 2157) Sep 7 11:58:54 Tower ntpd[1527]: Listen normally on 0 lo 127.0.0.1:123 Sep 7 11:58:54 Tower ntpd[1527]: Listen normally on 1 br0 10.27.33.198:123 Sep 7 11:58:54 Tower ntpd[1527]: Listen normally on 2 lo [::1]:123 Sep 7 11:58:54 Tower ntpd[1527]: Listening on routing socket on fd #19 for interface updates Sep 7 11:58:54 Tower ntpd[1527]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Sep 7 11:58:54 Tower ntpd[1527]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Sep 7 11:58:54 Tower root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp Sep 7 12:00:17 Tower ntpd[1527]: receive: Unexpected origin timestamp 0xe6c33036.73536c7b does not match aorg 0000000000.00000000 from server@216.239.35.12 xmt 0xe6c33081.7014ee6e10.27.33.1 is the pfsense router.
