We include a standard MIB, plus some additional options for pf stats. For determining whether a connection is down, there isn't anything in SNMP that checks gateway status. You'd probably just use the interface counters and alarm when it has less throughput than what's normal for that day and time of day.
There is still the problem in PfSense 2.1.3 : #snmpwalk -v 1 -c public X.X.X.X .22.214.171.124.126.96.36.199
SNMPv2-MIB::sysDescr.0 = STRING: pfSense xxxx.xxxxx.xxxx 2.1.3-RELEASE pfSense FreeBSD 8.3-RELEASE-p16 amd64 # snmpwalk -v 1 -c public X.X.X.X .188.8.131.52.4.1.123184.108.40.206.9.3
Error in packet.
Reason: (genError) A general failure occured
Failed object: SNMPv2-SMI::enterprises.123220.127.116.11.9.3
pfSense's SNMP service is under Services > SNMP. Enable it there and choose the modules you want to enabled. That will let you poll the firewall for SNMP data about itself. If the client is located over a VPN, choose the LAN interface for binding to make sure the replies are properly handled on the firewall.
For other devices, you'd need to poll them directly using SNMP. How that would be handled depends on where your SNMP client is. If it's local or over a VPN, just use the IPs directly. If it is on WAN, you probably shouldn't be querying SNMP directly that way since it could leak potentially sensitive information.
bsnmpd can have some problems with snmpbulkget (see other existing threads on this) and snmpwalk in general on some systems. If you can setup your SNMP queries to request only specific OIDs and not walk the entire SNMP tree it would probably work.
The problem lies in how FreeBSD and others source UDP replies from hosts with multiple interfaces in certain cases, and also how IPsec works with the FreeBSD kernel.
The SNMP daemon will always reply to a query from the interface IP "closest" to the client, from a routing perspective. If you have no direct connection and no static route, it will reply via the default route (WAN IP), and the WAN IP isn't a part of the IPsec tunnel, so the traffic doesn't get back to the client, and even if it did, the IP wouldn't match and it would be dropped.
Binding to the LAN IP forces it to only use the one single IP, which then matches IPsec and it works. Because it isn't bound to any other IP, it can't use the "wrong" one to reply. This is the best fix. If you need to reach it via another interface, use port forwards to nudge the traffic to the LAN IP.
The routing workaround fixes it because the route will make the firewall send the traffic out the LAN IP, and it is then grabbed by IPsec.
For the same reason you also can't query the SNMP daemon on an interface IP that is "far" from you. For example if you're in the LAN subnet, you can't query the WAN address and get a proper reply because the response will comes from the LAN IP, when the query went to the WAN IP, and it will be dropped.
Feeling too complicated. already more than I can solve
I decided to change the way
Because all I need from both WAN and LAN sides are receiving the data can either
It isn't by default, you have to permit it with firewall rules. and not have SNMP bound to LAN only.
Of course, I know the firewall to allow to connect to
I tried WAN interfaces allow access to UDP 161 PORT TO WAN ADDRESS
I tried all LAN interfaces to allow
Set SNMP for LAN and WAN NAT entry. failed
(Of course, firewall rules are automatically LINK)
Descr The time (in hundredths of a second) since the network management portion of the system was last re-initialized.
Descr The amount of time since this host was last initialized. Note that this is different from sysUpTime in the SNMPv2-MIB [RFC1907] because sysUpTime is the uptime of the network management portion of the system.
If memory serves, I changes the trap destination about 2 weeks ago (340 hours-or-so), that would've re-started the snmp daemon.
Not sure about that - I think if you install nrpe2 it should show the command paths in the package settings.
oops. Didn't know that pfSense was already installed to the system and had NRPEv2 option in the web GUI. …Services --> NRPEv2
1 - Created plugin -
real_rtt=`cut -f7 -d '|' /tmp/apinger.status | sed s/..$//`
rtt=`cut -f7 -d '|' /tmp/apinger.status | sed s/......$//`
isp=`cut -f3 -d '|' /tmp/apinger.status`
ispIP=`cut -f1 -d '|' /tmp/apinger.status`
if [ $rtt -lt 50 ]
echo "Normal - $isp RTT OK for $ispIP : $real_rtt ms"
elif [ $rtt -gt 50 ] && [ $rtt -lt 100 ]
echo "Warning - $isp RTT Increasing for $ispIP : $real_rtt ms"
elif [ $rtt -gt 100 ]
echo "Alert - $isp RTT Critical for $ispIP : $real_rtt ms"
2 - SCPed plugin to /usr/local/libexec/nagios directory
3 - pfSense web GUI –> Services --> NRPEv2
4 - Create new entry with check_pfsense_gateway_rtt as name and select the same name from plugin drop down menu:
[attachment image 1]
5 - add entry to /etc/nagios/services.cfg
6 - add hostgroup entry to /etc/nagios/hosts.cfg for the pfsense
I already found a solution. I used the CheckWMI check, this allows you to ping via a remote host to an other remote host. For the people that are interested visit http://www.renzokuken.org/post/4231212752/how-to-ping-a-remote-server-from-a-remote-windows