DNS Resolver doesn't work with my university domain.
-
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.
-
see here
11:08:25.172578 IP ***.***.***.***.123 > 162.159.200.1.123: UDP, length 48That is your IP talking to that 162, see the .123 is the port your talking from the "source" port.. and then the .123 on the 162 address is the "destination" port
If you notice in my traffic, that 69 address is mine the source port is 23455, and the destination is 123..
When traffic is natted through pfsense the source port is almost always changed.. This is how napt (network address port translation) works.
So you could have your machine 192.168.1.100:X talking to 8.8.8.8:443 when pfsense nats it to your public IP it would be like this
Your public IP 1.2.3.4:Y going to 8.8.8.8:443
Its common for many ntp clients to use source port 123, pfsense would use that or should - here for example is client on my network talking to through pfsense to my ntp server.. Since they are on different vlans. See how its source port 123 to destination port 123
Its a possibility that your isp is blocking traffic that has a source port of 123, because the return traffic to that would be to 123.. So it would be good to see if you still don't get answers to ntp with the source port is not 123..
Any client behind pfsense trying to talk to ntp out on the internet, be it using 123 or not would be natted on pfsense to some other source port.
Which if your saying no ntp client works behind pfsense, that its most likely not the case - but its good to have that info to tell/show the ISP when you complain.
-
I'm not so sure anymore that my ISP is blocking it.
root@Tower:~# ntpq ntpq> v ntpq 4.2.8p15@1.3728-o Fri May 21 19:02:16 UTC 2021 (1) ntpq> pe remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 55 64 1 0.000 +0.000 0.000 +time2.google.co .GOOG. 1 u 42 64 1 137.169 -6.854 2.481 *a.st1.ntp.br .ONBR. 1 u 45 64 1 11.026 -4.679 1.775 lrtest2.ntp.ifs 143.107.229.211 2 u 42 64 1 18.545 -2.760 3.131 time.cloudflare 10.221.8.4 3 u 41 64 1 18.712 +2.339 3.138 ntpq>using:
time.google.com
a.st1.ntp.br
0.br.pool.ntp.org
pool.ntp.orgunraid is able to access it.
Pfsense is not.
Unraid is on my LAN that is accessing WAN behind Pfsense.
That makes zero sense to me. -
@fandangos well that points to my theory of them blocking source port 123..
If that is the case, then the simple solution is just point pfsense to that box for its ntp server. Then your other clients could either use pfsense for ntp, or also point to this device.
-
@johnpoz said in DNS Resolver doesn't work with my university domain.:
If that is the case, then the simple solution is just point pfsense to that box for its ntp server. Then your other clients could either use pfsense for ntp, or also point to this device.
That's what I'm doing.
My question is, does ntpq (out of the box since I changed nothing) uses other port that's not 123?Or how is it possible that ntpq is able to access those servers and pfsense is not?
If I understand everything so far, it is using port 123, or at least it should be. -
@fandangos it is very very common for ntp to use source of 123.. Its possible that some ntp clients might allow you to change - openntpd might, chrony might for example..
I do not believe there is anyway to change it in pfsense, there sure isn't in the gui, and I do not believe the client they use has anyway to do it.
So the simple solution is pick a box, your nas, whatever this tower box is - something that is on 24/7 and use that as your ntp server. Then just point pfsense to it, all your clients to it - or once you have pfsense syncing ntp to this server you pick to use on your network. Clients could just use pfsense as their ntp source, etc.
But really doesn't matter what source port a box your going to use as your ntp server on your network uses, since pfsense will change the source port to something other than 123 when it nats that traffic to the internet.
-
If you set an interface (or interfaces) for ntpd to listen on it will also use those for outbound requests. If WAN is not included it will NAT that traffic and change the source port:
WAN udp 172.21.16.10:41229 (192.168.10.1:123) -> 141.95.116.44:123 MULTIPLE:MULTIPLE 7 / 7 532 B / 532 B WAN udp 172.21.16.10:36854 (192.168.10.1:123) -> 201.217.3.85:123 MULTIPLE:MULTIPLE 7 / 7 532 B / 532 B WAN udp 172.21.16.10:49005 (192.168.10.1:123) -> 165.140.142.118:123 MULTIPLE:MULTIPLE 7 / 7 532 B / 532 B WAN udp 172.21.16.10:53482 (192.168.10.1:123) -> 46.165.252.57:123 MULTIPLE:MULTIPLE 7 / 7 532 B / 532 BSteve
-
@stephenw10 great idea steve - yup that should do it.
Mine doesn't have it selected - so try that first, that be much easier solution.
-
I did a packet capture while trying ntpq on unraid, selected ipv4 and udp only
I'm looking at the log for .123 only13:22:57.861449 IP ***.**.**.***.33801 > 216.239.35.0.123: UDP, length 48 13:22:57.861500 IP ***.**.**.***.62024 > 143.107.229.210.123: UDP, length 48 13:22:57.879592 IP 143.107.229.210.123 > ***.**.**.***.62024: UDP, length 48 13:22:57.920856 IP 216.239.35.0.123 > ***.**.**.***.33801: UDP, length 4813:22:59.920620 IP 216.239.35.0.123 > ***.**.**.***.33801: UDP, length 48 13:23:00.861400 IP ***.**.**.***.37425 > 201.49.148.135.123: UDP, length 48and
13:23:03.861526 IP ***.**.**.***.33801 > 216.239.35.0.123: UDP, length 48 13:23:03.861546 IP ***.**.**.***.62024 > 143.107.229.210.123: UDP, length 48 13:23:03.879777 IP 143.107.229.210.123 > ***.**.**.***.62024: UDP, length 48 13:23:03.920821 IP 216.239.35.0.123 > ***.**.**.***.33801: UDP, length 48 13:23:04.861879 IP ***.**.**.***.37425 > 201.49.148.135.123: UDP, length 48 13:23:04.861897 IP ***.**.**.***.37188 > 200.160.7.186.123: UDP, length 48 13:23:04.872419 IP 200.160.7.186.123 > ***.**.**.***.37188: UDP, length 48 13:23:04.885491 IP 201.49.148.135.123 > ***.**.**.***.37425: UDP, length 48 13:23:05.862358 IP ***.**.**.***.33801 > 216.239.35.0.123: UDP, length 48 13:23:05.862377 IP ***.**.**.***.62024 > 143.107.229.210.123: UDP, length 48 13:23:05.880758 IP 143.107.229.210.123 > ***.**.**.***.62024: UDP, length 48 13:23:05.921698 IP 216.239.35.0.123 > ***.**.**.***.33801: UDP, length 48 13:23:06.862783 IP ***.**.**.***.37425 > 201.49.148.135.123: UDP, length 48 13:23:06.862893 IP ***.**.**.***.37188 > 200.160.7.186.123: UDP, length 48So I get it, it's not blocked at all.
-
@stephenw10 said in DNS Resolver doesn't work with my university domain.:
If you set an interface (or interfaces) for ntpd to listen on it will also use those for outbound requests. If WAN is not included it will NAT that traffic and change the source port:
I'm not following anymore.
Are you suggesting creating a virtual interface on pfsense and route traffict trought it?
I don't know how to do it.oh, you mean just unselect WAN?
-
@fandangos yeah blocking source port 123 allows them to prevent you from running a ntp server to the public internet. Because into the isp 123 destination is blocked. So they prob are not actually blocking the source port, but destination port of 123 into the isp network, which your on. So when you use 123 as source, the answer would be to destination 123 into the isp network, which they block.
But this blocks your answers from getting to you as well because to answer you the answer uses destination 123
Prob doesn't effect most of their users, because the isp router is prob natting all the isp users traffic and changing the source port, etc. So those users never notice and issue.
Reason you seeing the problem is pfsense using its public wan IP never goes through a nat and uses the common normal source port for ntp of 123
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
-
@fandangos Yeah!!! great all sorted and didn't have to sit on hold with your isp, talking to someone that had no idea what your talking about.. And them telling you we do not block any outbound ports ;)
-
Can't thank you enough, guys.
Specially John that helped for days until this got figured out, one problem after another.Thanks a lot! :)))
