[solved] NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0

stephenw10

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.

eagle61

@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/27

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:~#

So most likely it sends back answer to client using bridge100 instead of bridge102.

eagle61

@eagle61

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

Bob.Dig

@eagle61 Maybe you have a Port Forward in place?

stephenw10

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?

eagle61

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:~#

eagle61

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

stephenw10

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#general

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.

Check the firewall logs.

Try switching the firewall state policy back to floating in 2.8 as a test in Sys > Adv > Firewall & NAT.

Bob.Dig

@eagle61 said in NTP / UDP Port 123 blocked since update 2.7.2 -> 2.8.0:

The ntp-Server has two default gateways

Why.

eagle61

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

stephenw10

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.