DNS Resolver doesn't work with my university domain.

johnpoz

see here

11:08:25.172578 IP ***.***.***.***.123 > 162.159.200.1.123: UDP, length 48

That 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.

Fandangos

@johnpoz

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.org

unraid 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.

johnpoz

@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.

Fandangos

@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.

johnpoz

@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.

stephenw10

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 B

Steve

johnpoz

@stephenw10 great idea steve - yup that should do it.

Mine doesn't have it selected - so try that first, that be much easier solution.

Fandangos

@johnpoz

I did a packet capture while trying ntpq on unraid, selected ipv4 and udp only
I'm looking at the log for .123 only

13: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 48

13: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 48

and

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 48

So I get it, it's not blocked at all.

Fandangos

@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?

johnpoz

@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

Fandangos

@johnpoz

It's alive!

johnpoz

@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 ;)

Fandangos

Can't thank you enough, guys.
Specially John that helped for days until this got figured out, one problem after another.

Thanks a lot! :)))

stephenw10

Wow, that's fun*. So the ISP is blocking the udp traffic with source port 123 because that's easier than actually using a stateful firewall?!

Fandangos

@stephenw10

Guess so, it's weird but I always had this problem. To be honest, I'm not sure why it started working for my unraid box.
It didn't a few months ago when I looked into this.

johnpoz

@fandangos glad could be of help.. Always fun getting to the actual root of a problem..

johnpoz

@stephenw10 nothing saying the security guy at isps have to be the sharpest crayon in the box ;) heheh

Our users don't need 123 inbound, only out. Never coming to think that 123 is the default/common source port as well for ntp. And they prob don't get many complaints, because most of their users are prob using the isp router and all their devices are behind a nat so would never see the problem to complain about it.

@Fandangos if you ever just sitting around hmmm, what could I do that would be painful - you could try calling your isp and point out to them the problem they have ;)

Gertjan

@johnpoz said in DNS Resolver doesn't work with my university domain.:

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

You mean :
When I use a modem device, and one PC hooked up to it, using for example PPPOE, this PC won't be able to 'ntp' neither ?
I know, this set up doesn't exist any more these days, but was quiet common in the old days.

I would like to understand what the reason for the ISP is to block this port 123.
ntp is a very low bandwidth service.
Router firewalls like pfSense can handle often TLS related functions, DNSSEC is just one of them, and using the correct time is not some kind of option.
So it should go back into it's LAN, to ask a NTP service (server), and that one goes back out to the net to sync ?
Strange ....

stephenw10

@gertjan said in DNS Resolver doesn't work with my university domain.:

When I use a modem device, and one PC hooked up to it, using for example PPPOE, this PC won't be able to 'ntp' neither ?

Exactly, it would fail because the service almost certainly uses 123 as the source port.
It would also fail through any NAT that did not change the source port.

They are blocking it because they do not want their users running NTP servers or more likely accidentally exposing NTP servers and being used in an amplification attack.
But they are blocking it incorrectly IMO. They seem to have blocked to/from port 123 at the user side. As though they are not using stateful filtering.

Steve

johnpoz

@gertjan said in DNS Resolver doesn't work with my university domain.:

I would like to understand what the reason for the ISP is to block this port 123.

While I agree it low bandwidth, but it is also a common amplification tool via for one that old monlist command, but pretty sure that was disabled many versions ago to prevent that attack vector.

But maybe they are just playing it safe because not like users keep their stuff updated all the time.. Look at here where they are still running like 2.3 versions of pfsense..

They could do it a different way to allow for source 123 to be answered, with yeah a stateful firewall. so if one of there users asks some ntp server with source port 123 that is allowed, but nonstateful traffic inbound to 123 would be denied. While sure udp is not really a stateful protocol, most firewalls do keep track of the state.

But that would be more work for them so they most likely just go the easy route. And don't monitor state of the users traffic and just block all inbound to their network on 123..