Bug 203264

We discovered this issue on 5 pfsense firewalls running pfsense 2.2.4(amd64), based on FreeBSD 10.1-RELEASE-p15.  I chose the amd64 in the hardware section above because we are running Intel Xeon CPU's and the verison of pfsense we are running is the 64-bit load.

All of the pfsense firewalls listed below are virtual, running on Intel CPU's in the same architecture. This is running on top of ESXi 5.5. All the pfsense VM's have open-tools installed.  One machine did not, but exhibited the same failures as the ones that did, tools were added and the behavior did not change. This is not CPU or disk space issue, or hardware, as these are running across 3 different hosts at the time of this writing.

Here is an correct result of an snmp walk of a pfesense 2.1.5 host, based on FreeBSD 8.3-RELEASE-p16:
snmpwalk -v2c -c <string> <host> IP-MIB::ipAdEntNetMask
IP-MIB::ipAdEntNetMask.0.0.0.0 = IpAddress: 0.0.0.0
IP-MIB::ipAdEntNetMask.10.0.8.1 = IpAddress: 255.255.255.255
IP-MIB::ipAdEntNetMask.10.10.10.100 = IpAddress: 255.255.255.255
IP-MIB::ipAdEntNetMask.64.141.171.33 = IpAddress: 255.255.255.0
IP-MIB::ipAdEntNetMask.127.0.0.1 = IpAddress: 255.0.0.0
IP-MIB::ipAdEntNetMask.172.16.15.185 = IpAddress: 255.255.255.0

We get two different results on 2.2.4 - one that does NOT crash the Zenos SNMP Interfaces modeler that lead us to test this (but is still incorrect):
snmpwalk -v2c -c <string2> <host2> IP-MIB::ipAdEntNetMask
IP-MIB::ipAdEntNetMask.0.0.0.0 = IpAddress: 0.0.0.0

And this is one of FOUR pfsense 2.2.4 hosts that DOES crash the Zenos SNMP Interfaces modeler, probably because the mask returned is invalid:
snmpwalk -v2c -c <string3> <host3> IP-MIB::ipAdEntNetMask
IP-MIB::ipAdEntNetMask.0.0.0.0 = IpAddress: 48.0.0.0



This is the output of an ifconfig on the host that returns the 48.0.0.0 mask:
$ ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:50:56:a3:61:3c
inet6 fe80::250:56ff:fea3:613c%em0 prefixlen 64 scopeid 0x1 
inet 64.141.187.132 netmask 0xffffff80 broadcast 64.141.187.255 
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:50:56:a3:3e:c3
inet6 fe80::250:56ff:fea3:3ec3%em1 prefixlen 64 scopeid 0x2 
inet so.me.ip.ad netmask 0xfffff800 broadcast so.me.ip.255 <- edited to remove private network info
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
pflog0: flags=100<PROMISC> metric 0 mtu 33144
pfsync0: flags=0<> metric 0 mtu 1500
syncpeer: 224.0.0.240 maxupd: 128 defer: on
syncok: 1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000 
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0<> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

As you can see, there is not a mask resembling 48.0.0.0. This system has 1 CPU with two cores, 1 Gig of RAM. It has 25 states in the state table at the moment, mbuf usage is 1270, no swap usage. It's using 12% of the 1 gig of RAM/ 4% of the 17 gig disk partition. All interfaces are running at 1000baseT full duplex.

Config.xml does not contain any reference to an IP or mask of 48.0.0.0.

bsnmpd is configured to ONLY listen on the WAN interface, and we have restricted who can access that interface to just a single /24 which we control. 

This appears to be a bug in bsnmpd.  I opened a ticket with pfsense and they replicated my results on a FreeBSD system running 10.2-STABLE, and told me that since bsnmp appears to have this issue across versions I needed to open a problem report with FreeBSD.  I have seen a report of similar behaviour in the pfsense redmine bug tracker from January of 2015, but no one has touched it, probably because it is an issue in FreeBSD.