[solved] NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0
-
@stephenw10 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:
I'd still guess that the server has no route back to LAN. Or perhaps anything outside it's own subnet.
That might be the problem. The ntp-Server has two default gateways.
bridge102 = 192.168.102.0/27
bridge100 = 192.168.0.0/27root@peladn-wi6:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default _gateway 0.0.0.0 UG 425 0 0 bridge100 default _gateway 0.0.0.0 UG 426 0 0 bridge102 (...) root@peladn-wi6:~#So most likely it sends back answer to client using bridge100 instead of bridge102.
-
It does not matter wich one i use
root@Lenovo-M30-70:~# ntpdate 192.168.0.7 ntpdig: no eligible servers root@Lenovo-M30-70:~# ntpdate 192.168.102.7 ntpdig: no eligible serversLenovo-M30-70 is 192.168.101.8 still no answer
The following is from Server IP 192.168.0.2
root@DebianServerVM2:~# ntpdate 192.168.0.7 2025-06-08 16:56:54.615259 (+0200) -0.000721 +/- 0.000536 192.168.0.7 s3 no-leap root@DebianServerVM2:~#So NTP-Serwer works fine from local net no pfsense inbetween
-
@eagle61 Maybe you have a Port Forward in place?
-
So 192.168.0.X and 192.168.102.X are subnets on pfSense directly?
Need all the details or we are just guessing.
Does that server have a route back to the LAN subnet specifically?
Can you ping the server instead of using ntp?
-
So i switched back to CE 2.7.2 and now and everything is running smooth
NTP client's result with IP 192.168.101.8 is now:
root@Lenovo-M30-70:~# ntpdate 192.168.102.7 2025-06-08 17:13:19.373672 (+0200) -0.436448 +/- 0.000817 192.168.102.7 s3 no-leap root@Lenovo-M30-70:~# -
@stephenw10 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:
So 192.168.0.X and 192.168.102.X are subnets on pfSense directly?
Need all the details or we are just guessing
All are local subnets of my pfsense:
This are the details:
LAN = 192.168.101.0/27 vtnet2 = 192.168.102.0/27 (WLAN) vtnet1 = 192.168.0.0/27 (DMZ)No Wireguard tunnel, no OpenVPN inbetween.
The client is in the LAN and allowed to access all networks. See rules above.
The following is still the NTP-Server:
root@peladn-wi6:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default _gateway 0.0.0.0 UG 425 0 0 bridge100 default _gateway 0.0.0.0 UG 426 0 0 bridge102 (...) root@peladn-wi6:~#Still two default gateways, nothing changed.
The only change now is i got back to 2.7.2, what was easy done since my pfsense is a VM (KVM/QEMU) and I replaced the pfsense.qcow2 with that out of backup before updating from 2.7.2 to 2.8.0.
-
OK so the ntp server doesn't have a more specific route to 192.168.101.0/27?
If it does, and it's not via 102.1, then the state policy change in 2.8 could come into play:
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html#generalIn 2.7.2 udp replies would be allowed on any interface. In 2.8, with the default policy, it will only allow replies on the same interface. Asymmetric traffic will be blocked.
Check the firewall logs.
Try switching the firewall state policy back to floating in 2.8 as a test in Sys > Adv > Firewall & NAT.
-
@eagle61 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:
The ntp-Server has two default gateways
Why.
-
@stephenw10 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:
In 2.7.2 udp replies would be allowed on any interface. In 2.8, with the default policy, it will only allow replies on the same interface. Asymmetric traffic will be blocked.
That was the solution. I toggled back to Floating using the State Policy option under System > Advanced on the Firewall & NAT tab.
-
Aha! Well in that case you should really find out what the asymmetry is and correct that. Using interface bound states is more secure. You may hit that asymmetry still in some other way and see more problems in the future.
It's almost certainly because that server is multi-homed and doesn't need to be.
