Ubuntu – No SNMP query responses from Ubuntu 14.04 LTS server client machine

Alright, I've got two VMs both running under ESXi. One VM is hosting Observium, which uses SNMP to grab its info. I pointed Observium at my ESXi host directly, and it worked fine, so there's no issue with Observium. Trying to add the device using the proper settings (tried SNMP v1, v2c, and v3), there is always no response from the server.

The hostname for the server in this case is cal, and the hostname for the client is default, just to clarify.

The client I'm sending SNMP requests to is a fresh install of Ubuntu Server 14.04 LTS. All I've done is install the snmpd package, and configure it.

Here's my /etc/snmp/snmpd.conf:

com2sec readonly default taylor
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly
view all included .1 80
access MyROGroup “” any noauth exact all none none
syslocation “San Francisco, CA”
syscontact email@somesite.com

To my understanding, placing default before the community name (which is taylor) means it will accept SNMP requests from any IP.

And my /etc/default/snmpd:

export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'
TRAPDRUN=no
TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'

So figuring I had configured everything just fine, I issue a snmpwalk to test:

taylor@cal:~$ snmpwalk -v 2c -c taylor default
Timeout: No Response from default

I can ping just fine:

taylor@cal:~$ ping default
PING default.mywebsite.com (192.168.1.130) 56(84) bytes of data.
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=1 ttl=64 time=0.350 ms
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=2 ttl=64 time=0.235 ms
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=3 ttl=64 time=0.192 ms

taylor@default:~$ ping cal
PING cal.taylorjthurlow.com (192.168.1.112) 56(84) bytes of data.
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=1 ttl=64 time=0.306 ms
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=2 ttl=64 time=0.188 ms
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=3 ttl=64 time=0.264 ms

Wanting to make sure we've got traffic, I issue a tcpdump on both the sending and receiving ends:

Sending (SNMP server):

02:22:51.569041 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:52.569547 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:53.570659 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:54.571775 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:55.572715 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:56.573874 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)

Receiving (SNMPD client):

02:22:51.858750 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:52.859290 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:53.860371 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:54.861495 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:55.862424 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:56.863590 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)

So, essentially the same thing, just slightly different timestamps. The concerning thing being that there's no response packets being sent. Alright, so maybe there's a firewall or a port issue.

I disabled Ubuntu's Uncomplicated Firewall with ufw disable and confirmed that it was not running with ufw status.

I then checked my iptables, which were empty from the new installation. I added incoming and outgoing rules for port 161 on the SNMPD client.

taylor@default:~$ sudo iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:161

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:161

Still having the same issue. Another post on either SuperUser or ServerFault was resolved for the same issue because their /etc/hosts.allow and iptables were blocking the traffic. Here are mine:

taylor@default:~$ cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.

taylor@default:~$ cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
#                  See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID

I'm out of ideas at this point. Any suggestions on what I can try to get this thing to actually reply to my SNMP queries?

EDIT:
Here's my /var/log/syslog on the client:

Dec  9 01:48:24 default snmpd[2888]: NET-SNMP version 5.7.2
Dec  9 01:48:27 default snmpd[2888]: Connection from UDP: [192.168.1.112]:41109->[192.168.1.130]:161
Dec  9 01:50:54 default kernel: [ 8359.253571] nf_conntrack version 0.5.0 (7951 buckets, 31804 max)
Dec  9 01:48:32 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:41109->[192.168.1.130]:161]
Dec  9 01:52:53 default snmpd[2888]: Connection from UDP: [192.168.1.112]:40482->[192.168.1.130]:161
Dec  9 01:54:05 default kernel: [ 8550.718971] ip6_tables: (C) 2000-2006 Netfilter Core Team
Dec  9 01:52:58 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:40482->[192.168.1.130]:161]
Dec  9 01:54:11 default snmpd[2888]: Connection from UDP: [192.168.1.112]:59617->[192.168.1.130]:161
Dec  9 01:54:16 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:59617->[192.168.1.130]:161]
Dec  9 01:56:43 default snmpd[2888]: Received TERM or STOP signal...  shutting down...
Dec  9 01:56:45 default snmpd[3165]: NET-SNMP version 5.7.2
Dec  9 02:00:06 default snmpd[3165]: Received TERM or STOP signal...  shutting down...
Dec  9 02:00:08 default snmpd[3216]: NET-SNMP version 5.7.2
Dec  9 02:00:18 default snmpd[3216]: Connection from UDP: [192.168.1.112]:45692->[192.168.1.130]:161
Dec  9 02:00:23 default snmpd[3216]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:45692->[192.168.1.130]:161]
Dec  9 02:02:36 default snmpd[3216]: Received TERM or STOP signal...  shutting down...
Dec  9 02:02:38 default snmpd[3242]: Error opening specified endpoint "udp:161"
Dec  9 02:02:38 default snmpd[3242]: Server Exiting with code 1
Dec  9 02:07:16 default snmpd[3281]: duplicate registration: MIB modules pass and pass (oid .1.3.6.1.4.1.4413.4.1).
Dec  9 02:07:16 default snmpd[3281]: Error opening specified endpoint "udp:161"
Dec  9 02:07:16 default snmpd[3281]: Server Exiting with code 1
Dec  9 02:17:01 default CRON[3283]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  9 02:23:55 default kernel: [10340.925233] device eth0 left promiscuous mode

Looks like some of it is due to me watching packets, and then there's a few mentions of Error opening specified endpoint "udp:161" but they're sporadic. Could be something.

EDIT: This was actually due to me trying agentAddress udp:161,udp6:[::1]:161. The logs only said it sporadically because I was enabling and disabling that line. So, back at square one.