Messages

I see the current release of OPNsense has a banner to warn you about custom proxy settings on the HA Settings page. Great to see :)

My money is on either the NIC driver or something being introduced through FBSD's VLAN handling. Or a combination of the two. It has to be happening on the source device when the packet is originally generated so it has to be OS, I think.

[except]

This is probably an OS issue rather than an OPNsense issue but here goes...

I have 8 OPNsense firewalls (4 pairs, 2 in each location). The firewalls are Deciso hardware. They are connected together via a layer 3 cloud (think MPLS/VPLS type service). Presentation to the firewalls is GBE copper as a tagged VLAN. This service uses a /24 for IP addressing, each firewall has its own IP and each pair shares a CARP IP. Layout is :

10.x.x.1  Site 1 VIP
10.x.x.2  Site 1 FW 1
10.x.x.3  Site 1 FW 2
10.x.x.4  Site 2 VIP
10.x.x.5  Site 2 FW 1
10.x.x.6  Site 2 FW 2
10.x.x.10 Site 3 VIP
10.x.x.11 Site 3 FW 1
10.x.x.12 Site 3 FW 1
10.x.x.13 Site 4 VIP
10.x.x.14 Site 4 FW 1
10.x.x.15 Site 5 FW 2

Each firewall has a firewall rule on the interface for this zone that permits all ICMP. Each firewall can ping (either from the CLI or dpinger via gateway monitoring) each other individual firewall. Each firewall can ping each other individual VIP except the one ending in .1, where pinging this address results in 128 duplicate packets being sent. The number 128 seems significant to me.

I did a packet capture on Site 3 FW 1 and what I see is the below:

Code Select Expand

14:14:35.094594 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097248 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097250 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097520 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097566 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097813 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097815 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097816 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097817 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097817 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097846 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097847 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098106 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098107 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098108 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098109 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098110 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098111 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098112 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098112 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098135 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098387 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098389 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098389 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098390 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098391 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098392 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098393 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098394 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098394 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098708 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098710 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098711 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098712 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098713 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098713 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098714 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098715 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098743 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098744 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098791 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099046 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099047 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099048 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099049 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099050 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099051 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099051 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099052 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099053 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099083 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099084 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099341 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099342 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099343 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099344 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099345 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099346 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099347 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099348 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099348 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099349 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099376 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099618 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099619 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099620 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099621 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099622 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099623 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099624 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099624 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099625 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099626 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099627 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099686 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099913 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099914 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099915 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099916 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099917 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099918 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099918 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099919 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099920 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099957 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100211 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100212 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100213 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100214 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100215 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100216 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100217 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100218 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100218 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100219 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100220 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100221 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100222 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100253 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100532 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100533 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100534 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100535 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100536 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100537 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100537 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100538 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100539 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100568 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100826 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100827 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100828 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100829 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100830 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100830 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100831 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100832 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100833 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100834 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100869 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100870 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101140 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101142 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101143 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101144 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101145 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101145 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9


Important observations, same sequence number on all 128 pings, and these are being sent from the firewall initiating the ping. These are duplicate requests being generated by the device I run tcpdump on, they are not duplicate responses. This capture was performed on the device ending .11. Both CLI/OS ping command and dpinger exhibit the same response (I expect dpinger is just executing ping behind the scenes). All other firewalls connected to this service exhibit the same behaviour when pinging .1, and only .1.

WTF?!

This was the root cause of my issue as well. Annoying that it was something so simple and yet I did not think of it!!

I am still having this issue, and I have delved a bit deeper. I can see that when the /ui/core/hasync_status page is loaded, it makes an API call to /api/core/hasync_status/version. On my firewalls (2 separate pairs in different networks) this API endpoint responds:

Code Select Expand

{
  "status": "error",
  "message": "parse error. not well formed"
}
I have seen reference to this error in old bugs around HA sync, for example
https://forum.opnsense.org/index.php?topic=20557.0
https://github.com/opnsense/core/issues/4533

A different bug but similar symptoms. I think it means that the IXR library cannot parse the config file, as in, it is not well formed XML. However unticking all of the different services to synchronise in the HA Settings page does not make a difference to me. Either way, the error message displayed in the web GUI is clearly unrelated to the error returned by the API, and is quite misleading!

How can I work out what bit of the config/HA setup IXR is saying is not well formed?

I have the same issue on 2 business edition firewalls. They were upgraded to 25.4 last week and since then the primary firewall displays "backup firewall unavailable (check user creds)". HA sync worked prior to the upgrade - I did one the same day, before upgrading. I have manually reset all passwords on both firewalls and it's made no difference, and as per the OP the rc.filter_synchronize script from the command line works fine.

tcpdump on either firewall (tcpdump -i igb0 port 443) shows no packets when clicking System -> High Availability -> Status, however plenty of PFSYNC traffic is visible when running tcpdump without the port specification. I can curl https://ha-peer-ip-address/ with no issues from the CLI.

CVE-2025-27516 affecting Jinja2 was fixed in community yesterday and isn't much older than that if at all exploitable. I already planned to hotfix business, but we also need to ensure that these things don't cause regressions first. But also:

plugins % git grep '|[^a-z]*attr' */*/src/opnsense/service/templates | wc -l
       0

core % git grep '|[^a-z]*attr' src/opnsense/service/templates | wc -l
       0

For CVE-2025-26466 it's a bit different. Medium score and DoS warrant patching and I agree it needs patching in the next release, though that's also where it would be patched at the latest anyway.  By default SSH is not exposed and you can even use IPS or firewall to rate limit.


Cheers,
Franco

Thank you Franco, that is very useful ammunition for me to go back with around Jinja2. Is there a way to pull the latest ssh package from ports while leaving the rest of opnsense alone?

Vulnerability scanners are blunt instruments, and context always matters. Your security team should adjust for that.

Based on your description, you already had the mitigations in place before either vulnerability was announced.

Priority wise, should you actually have an attacker on the management network there is an argument to be made that higher value targets exist there. Bringing down a bunch of FWs would hardly be a financially rewarding endeavour.

Yes, I am part of the security team :) The issue I am trying to resolve is really one of upward management, because reports from vulnerability scanners go directly to the customer in this environment which results in pressure. That is not an OPNsense problem though so wasn't going to go through all that detail on here, it is a customer management issue. Of course several technical mitigations are in place that significantly reduce the exposure.

We run an environment with several business edition Deciso hardware OPNsense firewalls. There are strong compliance and vulnerability requirements in the environment, as it is CNI adjacent. SLA requires vulnerabilities to be mitigated or patched within days not weeks, which goes against the patching ethos of business edition.

At the time of writing, there is CVE-2025-26466 affecting OpenSSH < 9.9p2 and CVE-2025-27516 affecting Jinja2. Is there a (supported?) way the updated versions of these packages can be pulled and installed to satisfy my SLA requirements around timely remediation of vulnerabilities? SSH just comes from ports (I think?) so I think that could be trivial, not so sure about Jinja2. The exposure is obviously reduced as these services are not exposed anywhere other than an internal management network, but that doesn't stop the vulnerability scanner sending big red warnings to the security team...

I've made a load of improvements to a plugin but have hit a blocker. The plugin in question has to write the IP address for a service to listen on, into a config file. I can use the templates structure for the plugins, e.g.

Code Select Expand

{%     if helpers.exists('interfaces.'+int+'.ipaddr') %}
{%       set interface_ip = helpers.getNodeByTag('interfaces.'+int+'.ipaddr') %}
{%       if '.' in interface_ip %}
--- do stuff here ---
{%       endif %}
{%     endif %}


However that gets the IP address out of the config file. If an interface is set to DHCP, or SLAAC (for the ipaddrv6 property) there is no IP address in that field. How do we cope with that in a plugin, is there an event handler for an IP address change that can update config files for running services?

Actually, I've had a bit of a think about this. What I will do (if it's OK with you) is fork the snmp plugin and update that with what I've done here instead. That way we aren't building very specific solutions for very specific products into the body of the main OS - modifying system components for the sake of one 3rd party product. Instead I will roll what I've written here into the snmp plugin.

That would be awesome!

Minimal mucking about:

Code Select Expand

./opnsense-version -o
FreeBSD|SMP|amd64|OPNsense|24.7.8|vmware|

That should mean you could add something into your snmpd.conf template like:

Code Select Expand

{% if OPNsense.netsnmp.general.enableobservium == '1' %}
extend .1.3.6.1.4.1.2021.7890.1 distro /usr/local/sbin/opnsense-version -o
extend .1.3.6.1.4.1.2021.7890.2 hardware /bin/kenv smbios.planar.product
extend .1.3.6.1.4.1.2021.7890.3 vendor /bin/kenv smbios.planar.maker
extend .1.3.6.1.4.1.2021.7890.4 serial /bin/kenv smbios.planar.serial
{% endif %}

And then not have to bundle the distro.sh from Observium. It's actually better than distro.sh which will never detect if you are running in a hypervisor - despite having logic to check if it is running in FreeBSD, it then tries to call the detectvirt binary which is a systemd tool that doesn't exist here.  My virtualisation detection is rudimentary though - it doesn't detect containers and I can only actually test it on vmware and hyper-v.

I will put this in a PR and see what Franco et al think  :)

Just from a quick view, the format Observium is expecting for OS info is:

${OS}|${KERNEL}|${ARCH}|${DISTRO}|${VERSION}|${VIRT}|${CONT}

We could easily modify the built-in opnsense-version script to add another parameter (say, -o) to output Observium format. You would then not need distro.sh which contains a large amount of irrelevant info (e.g. checking to see if we are running on Solaris). Then you haven't got to maintain Observium's distro.sh script inside an OPNsense plugin, bundle in the Observium license, etc etc.

I understand now. That revision is far too new to be on my production systems I'm afraid - most are business edition! I will investigate it though because I would be keen to do this in such a way that would work any any NMS rather than specific 3rd party scripts for 1 product - e.g. some (most?) of the data from distro.sh is already provided by the net-snmp plugin in this other OID which is referenced by other 3rd party tools. And as mentioned I also have a bunch of work on the os-net-snmp and os-lldpd plugins in flight  :)

Ah, no sorry I didn't see that bit. I've not installed that plugin because I'm not using Observium, however it is interesting they have chosen to do it that way, as the info about architecture, release, and OS name (e.g. the stuff I posted about above) is exposed by net-snmpd by ticking the 'Display Version in OID' tickbox without needing any additional plugins.

What else does that plugin do? It can't just be that! Off to investigate... shouldn't need to install a plugin to make an nms work