Not on 2.3.x, but on 2.4 we have a NET-SNMP package and you can make as many different communities as you like (with different access levels, too). Or even better, SNMPv3 authentication and encrypted transport.
While you might be able to fake that using it as a gateway with a monitor + SMTP notifications, realistically that's not feasible. The firewall isn't a monitoring system, you'd be better served by setting up a small monitoring system separate from the firewall (even something light like smokeping) to keep an eye on things like that for you.
Yep, agreed - you're absolutely right! I did try a custom command (manually edited /var/etc/snmpd.conf) - and the command does work, but it doesn't update on demand (just like you said), rather it executes on a preset / configured schedule. That may be OK though - is there a way to set the custom commands? If not, not a biggie - would just be handy.
nope, xen. Past pfsense versions I've ran in the exact same config had working 64 bit counters but a recent change in 2.3 made them go away. Plenty of other OS's running in VM's here have working 64 bit counters so I'm not sure how it would be a hypervisor issue
From the OpenNMS server, you can use the snmp-request tool in the $OPENNMS_HOME/bin directory.
For example, support that the IP address of the target node is 192.168.0.8, the community string is public, and the SNMP agent is enabled using the default port with SNMPv2, the command should look like this:
/opt/opennms/bin/snmp-request -c public -v 2c -Ow 192.168.0.8 .18.104.22.168.2.1.1
This is equivalent to execute an snmpwalk like this:
I found the cause of the problem. I used a special character ("ß") in the SNMP location field which is not valid (I simply overlooked that error). However, I was able to enter it on the "Services: SNMP" page and it caused a hick-up in the configuration. I think it might be a good idea to check that only USASCII characters are used for sysLocation and sysContact.
If you search the forum for that error, you'll find a similar thread from a week or two ago – someone tracked it down to a problem in the FreeBSD bsnmpd daemon and how it handles interface IP address queries from the SNMP client (in your case, Spiceworks or whatever NMS you have).
It's a problem in the FreeBSD bsnmpd daemon so it needs to be fixed upstream. We might have one of our devs look at it, if they have some time. See https://redmine.pfsense.org/issues/4298
I had to open a case on this with pfsense - they were able to replicate the problem not only in pfsense, but FreedBSD 10.2, which indicates that this is a bug in bsnmpd that needs to go to the attention of the FreeBSD project. I've submitted a problem report to FreeBSD here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203264 - hopefully I formatted ti well enough that it won't rate an immediate close :)
The RRD graphs had a similar problem where the WAN graph would show "real" traffic metrics, but the LAN graph would show 2x WAN. I think the root cause of that was a bug in the version of BSD that pfSense uses.
The two may be related, but I am not entirely sure. The RRD graphs in 2.2 report properly.
Ok, maybe I can clarify this some. I'm running 2.2.2 (now) and still have the problem. Yes, the RRD graphs in pfSense are correct. However, like many people, I use SNMP to monitor all of my routers (in this case, via MRTG).
SNMP numbers are incorrect on the router at my main site, and now at one remote site. I am using OpenVPN. I can't just reverse LAN numbers, because I'm multi-WAN at most sites - I want to see separate bandwidth for each WAN connection. When I say incorrect, in this case, it means that my outbound traffic numbers are doubled. Inbound traffic is correct.
So, the second site started showing this symptom after I started messing about with the traffic shaping that was on at the remote site. Now, even with traffic shaping off, I am seeing the doubled numbers. I can't fathom why messing about with traffic shaping would cause this to start…but it appears that it did.
Just an FYI - I can report that upgrading from 2.2.2 to 2.2.4 has resolved this for me on all of my pfSense routers.
SNMP is now reporting correct values.