Bug #7609
closed
NTP Status not parsing all NTP Access Restrictions preventing status display when it is actually allowed
0%
Description
Status/NTP displays "Statistics unavailable because ntpq and ntpdc queries are disabled in the NTP service settings", whenever noquery is set in in the Default NTP ACL, in spite of a specific ACL allowing 127.0.0.1 to query. The command line "ntpq -pn" work properly.
To Reproduce:
Start with pfSense synced to NTP peer(s) and the default NTP ACLs. In Service/NTP/ACLs, check Queries in the Default Access Restrictions. Add a Custom Access Restriction that will match 127.0.0.1 and does not have noquery checked. Save. SSH to the pfSense host and run "/usr/local/bin/ntpq -pn" and it will display the peers. Status/NTP complains as above and doesn't display any peers.
I am not even a PHP novice, let alone expert, but can follow the code logic. It appears that that status_ntpd.php is only checking the Default Access Restriction noquery setting before skipping the ntpq and throwing that error message. There really needs to be a best address match on all the NTP ACLs (including default) against 127.0.0.1 and then test the matching noquery entry. And the code to do so might go in services_ntpd_acls.php so it is only done when the ACLs are changed, and sets a flag for status_ntpd.php. That also provides an opportunity to tell the user their config choice has blocked pfSense from providing NTP status, and offer advice, when that occurs.
Updated by Nano Caiordo over 6 years ago
Pull request https://github.com/pfsense/pfsense/pull/3981
Updated by Renato Botelho about 6 years ago
- Status changed from New to Feedback
- Target version set to 2.4.4-GS
PR merged
Updated by Steve Wheeler about 6 years ago
I'm unable to duplicate the original issue in 2.4.4 or 2.3.5p1.
In both 2.4.4 and 2.4.5 setting a custom ACL does not allow access to ntdp for queries either from the command line or from the GUI NTP status page.
It does allow access from an external test client if it's IP is in the defined network though as expected.
In both 2.4.4 and 2.4.5 though the NTP status page immediately shows 'Statistics unavailable because ntpq and ntpdc queries are disabled in the NTP service settings' if the custom ACL allows 127.0.0.1. However in 2.4.5 a custom ACL for the WAN subnet has that p[age show instead: 'No peers found, is the ntp service running?' after a delay. As though the code sees the source as in that subnet but ntpd is not actually allowing it. That is different to 2.4.4 where it does not check as this bug describes.
So it is now checking but never matches 127.0.0.1.
Updated by Steve Wheeler about 6 years ago
- Status changed from Feedback to Resolved
Ok in both cases it was using v6 localhost as source, ::1/128.
Using that I was able to duplicate the original bug in 2.3.5p1 and 2.4.4 and confirm it does allow the Status > NTP page to display correctly in:
2.4.5-DEVELOPMENT (amd64) built on Mon Oct 01 01:24:24 EDT 2018 FreeBSD 11.2-RELEASE-p4
Updated by Anonymous about 6 years ago
- Target version changed from 2.4.4-GS to 2.4.4-p1
Updated by Anonymous about 6 years ago
- Target version changed from 2.4.4-p1 to 2.4.4-GS
Updated by Nano Caiordo about 6 years ago
As of ntp-4.2.6p5, it seems to require 'restrict -4 default' or to use 'restrict localhost' in ACL, what worked for me is 'restrict localhost'.
For now I have patched system_ntp_configure() to first match if '127.0.0.1' is in ACL, if so let it write the 127.0.0.1 ACL and append one for 'localhost' using the same ACL rules.
Yes by default it uses IPv6, even if IPv6 is entirely disabled.
Updated by Nano Caiordo about 6 years ago
I would also add to not confuse or mix both issue. One was due PHP reading ACLs permissions but no setting them up for web viewing, the latter is instead a config issue due to package upgrade.
1. I realized the above patch will conflict with user permissions, in fact logged-in users with 'WebCfg - Status: NTP' permission set but browsing from a network in ACLs, will not be able to view online stats, which internally implies ntpq.
If the patch will be used to further match permissions, just let it be otherwise it could instead generate new redmine issues.
A second patch could instead let the status page output the query result for web browsing, letting pfSense permissions win.
2. Even by using only 'restrict localhost', without it's octet rule, seems to be just fine.
2.4.5-DEVELOPMENT (amd64) built on Wed Oct 03 16:11:30 EDT 2018 FreeBSD 11.2-RELEASE-p4
Updated by Paul K almost 6 years ago
As of 2.4.4-p2 issue as described in the original post still exists and has not been resolved.
There are a couple things to keep in mind though.
If "Allow IPv6" is set to yes, then "status_ntpd.php" page will execute command "ntpq -pn", which, as Steve Wheeler noted, will connect to ntp over IPv6 (::1). In that case we need to add ::1/128 to ACLs on NTP config page for the command to work. 
If "Allow IPv6" is set to no, then "status_ntpd.php" page will execute command "ntpq -pn -4" which will connect to 127.0.0.1. In that case we need to add 127.0.0.1/32 to ACLs on NTP config page for the command to work.
Currently status_ntpd.php performs following check:
if (ip_in_subnet($_SERVER['REMOTE_ADDR'], "{$v['acl_network']}/{$v['mask']}")) {
but it needs to check if ACL network is either ::1/128 or 127.0.0.1/32
Updated by robi robi almost 5 years ago
Can anyone share the solution/patch for this?
We're using pfSense as a GPS-based NTP server which is part of pool.ntp.org - but it's really annoying that with the recommended NTP security setup (restrict default kod limited nomodify noquery nopeer notrap) the status of the service shows just an error message, although 127.0.0.1/32 is added as an exception.
Updated by Jim Pingle almost 5 years ago
The original problem was resolved, the later report is a slightly different edge case. The new issue is not the original bug, but a variation of it. The new problem should be in a new issue since this was closed out several versions ago.