Trouble monitoring Untangle

[boy412]

This seems like more of a Cacti issue than an Untangle issue, but I'm sorry if I'm barking up the wrong tree.



Recently we re-created the VM running our Untangle firewall. Monitoring was working fine for the existing VM (Untangle v8_x86) but when we fired up our new Untangle VM (v9_x64) the Cacti monitoring broke. We enabled SNMP in Untangle and used the EXACT same settings from our previous VM (community, etc) but for whatever reason we are getting SNMP errors in Cacti.

I verified SNMP was running on the new box but I am unsure what I should try next?

[chadd]

This seems like more of a Cacti issue than an Untangle issue, but I'm sorry if I'm barking up the wrong tree.



Recently we re-created the VM running our Untangle firewall. Monitoring was working fine for the existing VM (Untangle v8_x86) but when we fired up our new Untangle VM (v9_x64) the Cacti monitoring broke. We enabled SNMP in Untangle and used the EXACT same settings from our previous VM (community, etc) but for whatever reason we are getting SNMP errors in Cacti.

I verified SNMP was running on the new box but I am unsure what I should try next?

What happens when you do the following from the Cacti server:

snmpwalk -v 2c -c 'community_string' [IP ADDRESS OF THE Untangle server]

example:

snmpwalk -v 2c -c 'readstring' 10.10.10.10

What is the error, if anything? (don't post the entire output from a successful walk though

-chadd.

[boy412]

If I run an snmpwalk from the Untangle VM itself I get results.

Code: Select all

snmpwalk -v 2c -c 'd1g1tal' localhost
SNMPv2-MIB::sysDescr.0 = STRING: Linux momus.cdia.local 2.6.26-2-untangle-amd64 #1 SMP Thu May 12 04:20:33 PDT 2011 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2600603) 7:13:26.03
SNMPv2-MIB::sysContact.0 = STRING: Momus
SNMPv2-MIB::sysName.0 = STRING: momus.cdia.local
SNMPv2-MIB::sysLocation.0 = STRING: Data Closet
SNMPv2-MIB::sysServices.0 = INTEGER: 78
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
...

If I run the snmp walk from any machine on the LAN it times out. I'm pretty stumped. I've posted this problem over on the Untangle forums as well, so maybe I will get some answers there. Regardless I will post back once I have figured this out.

Thanks...

[chadd]

If I run an snmpwalk from the Untangle VM itself I get results.

Code: Select all

snmpwalk -v 2c -c 'd1g1tal' localhost
SNMPv2-MIB::sysDescr.0 = STRING: Linux momus.cdia.local 2.6.26-2-untangle-amd64 #1 SMP Thu May 12 04:20:33 PDT 2011 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2600603) 7:13:26.03
SNMPv2-MIB::sysContact.0 = STRING: Momus
SNMPv2-MIB::sysName.0 = STRING: momus.cdia.local
SNMPv2-MIB::sysLocation.0 = STRING: Data Closet
SNMPv2-MIB::sysServices.0 = INTEGER: 78
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
...

If I run the snmp walk from any machine on the LAN it times out. I'm pretty stumped. I've posted this problem over on the Untangle forums as well, so maybe I will get some answers there. Regardless I will post back once I have figured this out.

Thanks...

Looks like this is a Linux box... I have never configured an "Untangle", but if it is using SNMPD, you will have to configure an allowed host, subnet, etc. in /etc/snmp.conf. It is likely that SNMPD is dropping the traffic that is sourced from outside the box.

I would start there. Good luck.

-chadd.

[boy412]

Yep. Untangle is based on Debian...

This has got to be an issue with Untangle. I ended up enabling a packet rule that allows SNMP traffic on ALL interfaces. Lo and behold Cacti started receiving SNMP data from this host. Still working with Untangle support to see why this might be necessary...because it shouldn't.

[seaquest33]

To be honnest, I guest this is an Untangle issue cause by using the shell and add an iptables entry on the 161 UDP port, it's working. Otherwise, it doesn't work well.

iptables -I INPUT 1 -i ethx -p udp --dport 161 -j ACCEPT

where ethx is your internal interface ID.

Martin