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

eagle61

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

stephenw10

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

eagle61

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

This 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

Gertjan

@eagle61

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.

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.