US Based Sonicwall Support
-
Or, if you ACTUALLY want support, move to a supported product. SW isn't exactly a product family meant for supported use. It's a trainwreck.
-
We constantly move people off of SonicWall rather than try to support them. It's cheaper to buy something better than to support all of the continuous SW problems. Literally cheaper to replace than to support.
-
@JasGot I am not sure where you are based on but I have had different Sonicwall Support Cases and I would say at least 95% of the issues I have been able to walk through the Tech without actually logging in and providing the information through email such as logs and errors. However I can understand your concerns.
-
@dbeato said in US Based Sonicwall Support:
@JasGot I am not sure where you are based on but I have had different Sonicwall Support Cases and I would say at least 95% of the issues I have been able to walk through the Tech without actually logging in and providing the information through email such as logs and errors. However I can understand your concerns.
I didn't care to go to deep, but we refuse all remote access to the devices unless we are in a time crunch AND have an easy to understand US support person on the other end. We support 715 SW devices, so we have a couple of things in our favor from the get go. We know more than their first level support and most of their second level support. And, the number of issues we run into that we haven't already seen and resolved, is about one a year. we've had to call SW support twice this week; I don;t remember the last time we called them.
It was funny when the guy said "We can't help you if we can't remote into your computer to log into the device." I told him we had been servicing SW devices since they were called Sonic Systems, about 20 years. And until just a few years ago, remote support was not even an option. He didn't have much to say after that.
The second level guy explained the #1 reason they want to remote in and log into the device is to confirm Serial # and validate Support. He said they get hundreds of calls a day from people providing a supported serial number for help on a non supported device. Remote access is the only way they can quickly combat it.
-
@JasGot said in US Based Sonicwall Support:
The second level guy explained the #1 reason they want to remote in and log into the device is to confirm Serial # and validate Support. He said they get hundreds of calls a day from people providing a supported serial number for help on a non supported device. Remote access is the only way they can quickly combat it.
Kinda makes sense. That's a risk of a "pay for support contract" support model, they constantly need to verify accounts and payment and license.
-
@scottalanmiller said in US Based Sonicwall Support:
Or, if you ACTUALLY want support, move to a supported product. SW isn't exactly a product family meant for supported use. It's a trainwreck.
It's all the owner uses where I work right now. Doing simple things is so hard it's not even funny. Give me an instance of VyOS and watch my productivity go through the roof!
-
@travisdh1 said in US Based Sonicwall Support:
@scottalanmiller said in US Based Sonicwall Support:
Or, if you ACTUALLY want support, move to a supported product. SW isn't exactly a product family meant for supported use. It's a trainwreck.
It's all the owner uses where I work right now. Doing simple things is so hard it's not even funny. Give me an instance of VyOS and watch my productivity go through the roof!
Dealing with phones, we often get vendors who only provide "how to fix your router" instructions for SonicWall, because essentially all router problems breaking UDP traffic are from SW. It's just assumed that if your router doesn't work, it must be a SW. They don't even state it, they figure it's safe to just treat all problems as being SW specific and they are probably right. When we do the same thing, we always start by asking if it is a SW because it's almost always the case.
-
@scottalanmiller said in US Based Sonicwall Support:
ng UDP traffic are from SW
Yes, because Sonicwall has a default of 30 Seconds UDP Timeout and Consistent NAT is not enabled by default. Same for other devices such as all the devices SIP-ALG need to be disabled and such.
-
@dbeato said in US Based Sonicwall Support:
@scottalanmiller said in US Based Sonicwall Support:
ng UDP traffic are from SW
Yes, because Sonicwall has a default of 30 Seconds UDP Timeout and Consistent NAT is not enabled by default. Same for other devices such as all the devices SIP-ALG need to be disabled and such.
There are some devices where SIP-ALG can be left on because it works. And Consistent NAT is a SW thing, it's not a universal term, lol.
-
@scottalanmiller Oh yeah, I wasn't saying it is normal but that is the main issue we find when dealing with Sonicwall and VoIP. That was my point.
-
@dbeato said in US Based Sonicwall Support:
Sonicwall has a default of 30 Seconds UDP Timeout
What do you set this to?
-
@JasGot said in US Based Sonicwall Support:
@dbeato said in US Based Sonicwall Support:
Sonicwall has a default of 30 Seconds UDP Timeout
What do you set this to?
Something more like 360. At 30 you tend to drop calls.
-
@JasGot said in US Based Sonicwall Support:
@dbeato said in US Based Sonicwall Support:
Sonicwall has a default of 30 Seconds UDP Timeout
What do you set this to?
Sophos says that most providers request 150 seconds.
For comparison, most vendors (SonicWall included) keep TCP Timeouts to closer to 15 minutes, but UDP to seconds. Not that their logic isn't good, but the gap can be pretty huge. It's really easy to have a call where there is silence (and silence suppression) for 30+ seconds causing the UDP connection to drop.
You don't want it to stay open for forever, but there's little value to closing it quickly either. The security risks are essentially zero.
-
@JasGot said in US Based Sonicwall Support:
@dbeato said in US Based Sonicwall Support:
Sonicwall has a default of 30 Seconds UDP Timeout
What do you set this to?
I set it to 300 and some up to 600 depending,.
