[solved] NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0
-
Since update 2.7.2 -> 2.8.0 clients in LAN can't reach dedicated ntp-Server via udp 123 in vtnet2. It seems some not visible unknown Firewall Rules block udp-Port 123.
I did not changed rules after update 2.7.2 -> 2.8.0.
pfsense NTP is not enabled. So no reason to block udp Port 123
So do not really understand why pfsense block udp Port 123
-
@eagle61 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:
clients in LAN can't reach dedicated ntp-Server via udp 123 in vtnet2.
Where is vtnet2?
Does that server have a route back to LAN?
-
@stephenw10 Well one client is 192.168.101.8
I am able to ping 192.168.101.8 from ntp-Server so think the route back is givenThis is result of:
ntpdate 192.168.102.7 ntpdig: no eligible servers
in 192.168.101.8
Do i put same client in 192.168.102.xxx-Network i got a response from ntp-Server
-
Your LAN devices can go anywhere - no restictions :
If :
is situated in ones of these :
(maybe not OpenVPN or WGTUN0)
then your LAN devices can access these networks/IPs.@eagle61 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:
It seems some not visible unknown Firewall Rules block udp-Port 123.
Create yourself a block rule like this - on the last line on LAN :
and see for yourself it never logs, because it will never match, as the former two rules match for all possible traffic.
So it won't be the final hidden firewall rule, identical to this 'block all' rule that block something neither.You can also packet capture on your LAN for UDP 123 and destination IP "192.168.102.7" and check if ntp traffic arrives at the LAN gates.
Then packet capture on the 192.168.102.0/24 network so you'll see the same traffic going to "192.168.102.7" NTP server. -
OK so your LAN subnet is 192.168.101.0/24? Where is 192.168.102.0/24?
I'd still guess that the server has no route back to LAN. Or perhaps anything outside it's own subnet.
-
@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 servers
Lenovo-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.