Shivering on the 49th Parallel
Monday, 30 August 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, 30 August 2010 08:13:49 (Pacific Standard Time, UTC-08:00) | Comments [2] | Tech | Hardware | Networking#
Wednesday, 18 August 2010

I’ve written before about what a huge, horrible, steaming pile of horse shit you have to wade through to install a 32-bit (x86) driver on a 64-bit (x64) server. It’s SO counter-intuitive it makes me want to scrape my eyeballs out with a grapefruit spoon and then chop off my fingers so I won’t be able to see a computer or type ever again.

In a nutshell, you need to have a 32-bit client running Vista or Windows 7, install “the full meal deal” printer driver on that client, THEN connect to the 64-bit server’s printer share (\\server\printer) and then tell it to use the existing driver. That will then UPLOAD the driver from the client machine to the server and make it available to other 32-bit clients who try to connect to it.

Today I’m in the opposite situation. I PURPOSELY set up a 32-bit Windows Server 2008 (not R2, which is 64-bit only) to run my print queues because 99.9% of my network is 32-bit Windows XP clients and I didn’t want to have to go through this rigmarole for every single one of them. *MY* laptop, however is running Windows 7 Professional 64-bit and it’s unable to connect to the shared printers on the 32-bit server.

Rather than duplicate the steps above, since I was feeling saucy and experimental, I went the other(old) way around. On the 32-bit server, I opened the printer properties, went to the sharing tab and clicked on Additional Drivers. I checked the 64-bit box and it asked me for a driver. I clicked Browse. I navigated to the folder where I had the 64-bit driver .inf file for the printer, selected it and clicked OK.

Fast-forward a few seconds and the window closed, and the box was checked. Just like that. Just how it USED to be in older versions of Windows Server. I went back to my laptop, tried to connect to the printer, and this time instead of failing and saying “Driver Unknown” or even worse, the  0x0004005 error which is one of the more generic error codes you’ll ever see. (I always thought it was “Access Denied”, but that’s just ONE of the errors it COULD be.) Up came a NEW dialog box. Do you trust this printer driver? Yes, of course I do. Just like that, it mapped the printer, using the 64-bit driver on the 32-bit server.

If it’s so bloody easy to do that with a 64-bit driver on a 32-bit server, why the HELL is it SO difficult and bass-ackwards to do it on a 32-bit driver with a 64-bit server??

Wednesday, 18 August 2010 10:09:35 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Deployment | Hardware | Microsoft | Networking | Servers | Windows#
Search
Archive
Links
Categories
Admin Login
Sign In
Blogroll
Themes
Pick a theme: