Shivering on the 49th Parallel
Monday, August 30, 2010

About a year ago or so, I tried to enable SNMP monitoring on m SonicWall TZ170. SNMP is useful for monitoring things like bandwidth usage (by port… so in the TZ170’s case it would tell me how much traffic this hour/day/week/month/year/etc had been funneled through the LAN connection and each of the WAN connections) I wrestled with it for a week or so, failed and gave up. I read the documentation, I configured everything correctly (according to the docs) and… nothing.

Earlier this summer, my TZ170 started flaking out. It would stop responding (like a reboot) for 30 seconds or so. Two times this morning, another time in the afternoon, again overnight… and when it did it took down both internet connections, incoming and outgoing email and all the inter-office VPN links. Not a great situation. By the time anyone noticed and called, it would be back up again. The TZ170 has been discontinued for awhile now, and I wasn’t even able to get any more from a used/recertified reseller in California that had kept me going for awhile. Fortunately, the newer TZ210 is backwards compatible with the TZ170s AND I was able to take advantage of the competitive upgrade to get one cheap cheap, if I signed up for three years of SonicWALL services (content filtering, gateway antivirus, etc).

The TZ210 is great. Each of it’s 8 ports can be configured as a LAN or a WAN port which gives you a lot of flexibility. With the help of a local Sonicwall Partner/technician we were even able to export the settings on the old TZ170 and import it onto the TZ210 and then just re-configure a few things and be back up and running in an hour or so, rather than a day or so of re-creating all the settings and VPN tunnels manually. We even upgraded the VPN tunnels to a better encryption scheme and documented everything (now where did I save that text file…)

Now that I had 8 more-configurable ports, I decided to give the SNMP monitoring another shot. I installed PRTG freeware version on a spare computer, downloaded the MIBs from SonicWall’s support site and then converted/imported them into PRTG as OIDs (Most of these TLAs are beyond even my knowledge…) I added a new device in PRTG and then attached some sensors to it… I gave it the IP address of the SonicWall TZ210, selected SNMP and… it failed.

I went into the SonicWall web interface and confirmed that the network interface’s properties had the SNMP checkbox checked, and that on the Administration tab, that SNMP was configured and had the IP address of the PRTG computer entered and that the community string was set correctly, but it still failed.

Using some of the PRTG testing tools, there was flat-out no response from the SonicWall on port 161 or 162 (the default SNMP ports). Without breaking out a packet sniffer, I deduced that the SonicWALL was dropping the packets. I went to the Firewall config and added a rule allowing LAN to LAN using protocol SNMP. Still nothing.

At that point (late last week) I gave up (again). I did some Googling and came across a couple of entries on Experts Exchange, but even though I have a login it wouldn’t show me the answer, instead telling me I needed to become an expert or pay $12.95/month to see the answer. Lame. That’s new…

I bitched about it on Twitter, stating it was too bad that I couldn’t automatically append a “-Experts-exchange.com” to all my queries to make sure I didn’t get any (now useless) search results from their site. Someone responded that if you follow a link from Google or Bing directly to Experts-Exchange, it will show the answer if you scroll down past all the ads… which is the behavior I was used to, but wasn’t happening on these particular articles.

I tried the SonicWALL forums, and people were using SNMP, so it wasn’t broken or anything… Ultimately I opened a support ticket with SonicWALL (hey I paid for 3 years of it, may as well make use of it!) and they called me first thing this morning and got it sorted out.

I'm not sure if SonicWALL does things differently from the SNMP spec… but then again I’m not an SNMP expert who would know the difference. Here’s the gist of what Darshan the tech went over with me:

  • You DO need the IP address of the system/software that’s monitoring the SNMP does have to be entered on the SNMP configuration page.
  • You DO need the checkbox on the network interface page does have to have SNMP checked.
  • You DO NOT need to create a firewall rule allowing SNMP traffic from LAN to LAN on the firewall. When it’s configured correctly, it auto-creates one that you can’t change.
  • You DO have to use the SonicWALL MIBs that are specific to each model of firewall.

We did end up doing a packet capture and seeing that the SNMP packets were being dropped, which led us back to the Firewall config page and removal of the custom firewall rule. Once we did that (and I think this is the key) we removed the SNMP checkbox from the interface config, let the firewall save/update it’s settings and then re-enabled it. After that, PRTG magically worked.

Now I just have to figure out which settings and ports I want to monitor and get those set up in PRTG! Smile

Monday, August 30, 2010 8:13:49 AM (Pacific Standard Time, UTC-08:00) | Comments [2] | Tech | Hardware | Networking#
Monday, April 16, 2012 3:05:56 PM (Pacific Standard Time, UTC-08:00)
Thanks! I had most of the steps, I saw the packets being dropped. I just didn't have the patience to uncheck SNMP, wait, and then re-check it, which was the key. Great info!
Hammer
Wednesday, August 22, 2012 12:49:36 PM (Pacific Standard Time, UTC-08:00)
Thanks for this article. I had this same issue on a Sonicwall NSA 240 running firmware SonicOS Enhanced 5.8.1.4-43o . Spent weeks trying to figure it out. Sonicwall support really needs to update their knowledge base. Wasted so much time on this issue when I was attempting to configure OpenNMS when I ran into this bug.
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Search
Archive
Links
Categories
Admin Login
Sign In
Blogroll
Themes
Pick a theme: