I’m pretty frustrated with SonicWALL right now. Sure, they have reasonably priced equipment for the small/medium sized businesses, but if you’re trying to be a security company that plays with the big boys, pony up the cash to pay some technical support reps that have a clue. This is going to be a long one folks…

I’ve expressed my frustrations with SonicWALL before in regards to the fact that, evidently to get the problem fixed the quick and dirty way to keep call times down, the first thing the support rep asks for is a tech support report (TSR). This is a file that contains all sorts of information about how to eviscerate the underbelly of your network, should it fall into the wrong hands. It contains things like VPN keys, radius shared secrets, saved Active Directory passwords (for some of their VPN appliance applications), IP schemes for your internal network, firewall rulesets, hostnames, etc. All of this in plain text. It appears the only thing that is obfuscated at all is the list of account passwords for the local accounts on the device. VERY poor practice. And all of this is as secure as: 1) the password to my account OR 2) email…yup…email…please send us all this sensitive information as an unencrypted email attachment. Yeah…uh-huh.

The problem I’m fighting now with them is in regards to an SSL-VPN 2000…their mid-level SSL VPN box. The gist of it is you poke a hole through your firewall on port 443 so that users outside can establish an SSL connection to this device and it serves them the content you have chosen. It has some pretty slick stuff as far as Java RDP and Citrix clients, decent Windows filesharing and something they call (I think) Network Xtender. It is an ActiveX control that works as a vpn client to attach the client computer to the corporate network. Pretty neat, if it works (haven’t tried it, but obviously someone in testing got it to work…). The device allows you to create different portals for different sets of users, each portal with a different hostname (like and Although this is documented thoroughly in the help documentation, according to SonicWALL support, it is not a common configuration. “Not a common configuration” means the first rep I talked to said it “probably won’t work”. I fought with him trying to explain that I DO NOT have to have the device
attached to the internet in order to test it directly. He gave me the typical request for a TSR from the device. I explained to him that sending that information out violates policy. He stated there were no passwords in the TSR. I corrected him and forced him to continue wihtout the report (offering to provide ANY information related to the problem to help him troubleshoot. He fumbled around trying to figure out the issue for about half an hour and then I got to talk to the “manager on the floor.” Both he and the “manager on the floor,” who picked up my call when I kept proving he didn’t know what he was talking about, agreed that I should have to have the SSL VPN device “connected to the internet” before I could test. After I gave them both a thorough explanation of the fundamentals of DNS, SSL and how networks work, the manager finally said, “I’m not sure why it is working.” I thanked him for his candor and we got off the phone with an open ticket I was supposed to hear back from them on.

A day later, I get an update to the ticket and a voicemail. The voicemail said, “This is the rep, we have duplicated the problem here, please send us a TSR and we will continue trying to find a solution.

Didn’t I explain I wasn’t sending that? Besides that, I would think they would need a TSR from me more if they couldn’t replicate my problem. If they can replicate my exact problem and confirm it is unexpected behavior, why can’t they fix it on their system first without needing my sensitive information??

I’m frustrated…

This entry was posted in bad security practices, SonicWALL. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *