pfSense » pfSense Plus

Netgate 6100, pfSense Plus 26.07-RELEASE.

ThreatGate remote feeds are only downloaded when the pfnet-controller
service starts, or when a feed entry is created or toggled. The
refresh_interval setting never triggers a scheduled re-download.

Observed behaviour:
- /var/db/threatgate/remote-feeds-sync-time is written only at controller
startup. It is not updated on any scheduled cycle.
- With refreshInterval set to 24h0m0s in /var/db/threatgate/config.json,
no re-download occurred after more than 24 hours of controller uptime.
- Feed content therefore stays frozen at whatever was downloaded when the
controller last started.

How this was found:
An abuse.ch feed had stopped being updated upstream (frozen since
2026-03-04). While investigating, it became clear that none of the other
nine feeds had been re-downloaded either, because the controller had been
running continuously since the previous day.

Additional notes:
- Restarting pfnet-controller does trigger a sync, but only if the delta
since the last recorded sync exceeds refresh_interval. Deleting
remote-feeds-sync-time does NOT force a sync; writing an old timestamp
into it does.
- Toggling a feed's enabled flag off and on reliably reloads that single
feed. This appears to be a side effect of the apply cycle rather than an
intended refresh mechanism.
- There is no API endpoint to refresh feeds. The OpenAPI contract exposes
only config, feeds, feeds/{id}, info, msgs, remotes and remotes/{id}.
By comparison the Snort package does provide
POST /services/snort/intf/{id}/action with start/stop/reload/restart.
- The remote feed schema exposes no last-updated timestamp, no entry count
and no status, so there is no way for an administrator to detect that a
feed has gone stale.

Impact:
IP reputation feeds silently age. An administrator has no indication that
protection is based on data that may be days or weeks old. On a security
product this is the same failure mode as reporting a feed as active when
its upstream source has stopped publishing.

Suggested fixes:
- Make the refresh_interval cycle actually trigger downloads.
- Add a manual refresh action to the API and GUI.
- Expose per-feed last-updated time and entry count.