US Based Sonicwall Support
-
@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,.
