Why does it take four days or more for SonicWALL support to response to any question?
Best Answers
-
CORRECT ANSWER
MasterRoshi
Moderator
@MPan, can't you take a pcap on both ends of the tunnel with "Monitor intermediate IPsec traffic" enabled and see if the ESP/ICMP packet that leaves site A arrives at Site B and vice versa? Pretty simple way to conclude if SNWL is at fault here. You will see missing sequence numbers for ICMP/ESP if the ISP is at fault. They may also be filtering or modifying ESP, so check for that too.
1 -
CORRECT ANSWER
MPan
Newbie ✭
WeWork is the culprit. WeWork had an ESP filter that caused the instability of the IPSec tunnel.
Thanks to @MASTERROSHI, @LARRY, and @TKWITS for pointing me to the right direction.
0
Answers
I called the support number and explained my issue over the phone politely. The technician reviewed my case, and the phone call abruptly terminated after four minutes. Is this just bad luck? Or is this a common issue with SonicWALL support?
I called the support number the 2nd time. A different technician answered. We started a Bomgar session. This time I left a call back number. Both Bomgar and call abruptly dropped at the same time. Let's see if I get a call back.
@MPan most of SonicWall's support technicians are working from home - not designated call centers - and the internet links do (unfortunately) drop during sessions. They are supposed to reach back out, but sometimes the technology prevents it from happening.
As for response time from ticket creation. If something is significant and requires immediate attention, my approach has been to create the case, snag the case number, and call the support phone number and indicate to the IVR that it is an existing case. Boom, someone gets started working on it after an inordinately long wait in a queue listening to that horrid music.
If the world wasn't experiencing a global pandemic, it would probably be easier...
No call back so far.
If you expect a faster resolution, I suggest you pick up the phone and call (says the guy who has averaged 2 dozen cases per quarter just this year).
@Larry, I do plan on calling back. However, I have meetings and other responsibilities that do not allow me to stay on hold indefinitely just to be cut off again and again.
The extended wait time is the bane of my existence, as well. I'm an MSP and maintain computer systems for dozens of clients, so sitting on hold is a major annoyance - I'll even let incoming client calls roll over to my cell phone just to keep the desk line connected.
SonicWall should - if it was at all concerned with it's partner and user base - significantly invest in their phone support system (e.g., by providing a "Press 1 for a call-back and not lose your place in line", "Press 2 to remain on hold", "Press 3 to hang up and try later" option, or, AT A BARE MINIMUM, have a system that says "Your estimated wait time is xx minutes"). But the thing is, they aren't and they won't.
@EnaBev, could you please pass along the previous comment?
Hi @MPan and @Larry
Thank you for your feedback. I've passed it along to our Support team. I'll let you know if I hear back about any possible additions/enhancements to their roadmap.
SonicWall does have a Knowledge Base, Technical Documents and a pretty stellar Community (biased) to serve as an alternative resource to Support. I understand not all answers will be outlined on the website, so you will need to contact support from time to time.
@MPan Have you tried posting your question in the community?
@ENABEV,
There was no call back on Friday. I called a 3rd time on Friday, and after a two hour Bomgar session I was advised to reset my Gen7 device to factory and reconfigure the device; that did not fix the problem.
I spend around three hours today so far working with SonicWALL support, there is still no solution.
Here is my issue, I build a tunnel interface between a Gen6 device and a Gen7 device on latest firmware. Tunnel is up and green, traffic is passing thru, however ICMP through the tunnel will work for a few hours and stop working. When it stops working, no configuration change will fix it. Tunnel remains green, but I cannot ping across the tunnel from either Gen6 or Gen7 device. I can see ICMP hitting the Gen7 device, forwards it, and the ICMP reply is consumed by Gen7, but I don't see ICMP reply hitting Gen6.
If I wait for a few hours, then everything might work arbitrarily for few hours at different time of the day.
When it does work, I can break it by changing one minor configuration on the G7 VPN spec, eg. lifetime; once it's broken, I cannot fix it even if I revert the changes.
Access rules are fine and there is no custom NAT. I tried down-grading the firmware on Gen7 as well, that did not work.
I read in one community thread with similar issue that the TZ device was bad, so I open a case trying to get the Gen7 replaced. So far, it's just looking the address objects, access rules, nat rules, route policies, and packet capture over and over again.
On Tuesday, 9/28, SonicWALL support could not locate any available senior tech, so we scheduled a support appointment later in the day. The afternoon appointment was a no show.
I tried to request update this morning and there has been no reply at end-of-day today.
My supervisor has inquired about RMA the Gen7 device, RMA for the device is approved, but SonicWALL refuses to refund the 3-year support contract for Gen7 device; this is very ironic. Our vendor is still pushing for the support contract refund.
I sent another status update request this morning, 9/30.
The Gen6 device is a TZ350.
The Gen7 device is a TZ270.
@ENABEV,
Day is almost over, and there is still no response from SonicWALL support on this important issue.
Do you have any recommendation on how to proceed? If I call the support line again, I will just go through the same address objects, access rules, NAT rules, route policies, and packet capture again with a different tech.
If you post your sanitized VPN config some of us with access to Gen 6 and 7 devices can try to re-create the issue.
On a side note I have a number of Gen 6 and 7 devices with VPNs between with no issues passing ICMP or other traffic.
@TKWITS, the VPN configure was rebuilt by SonicWALL support. I believe the Gen7 I have is defective, however I cannot get the support to replace the Gen7. After the support hit the wall, communication ceases.
There is no NAT since all the subnets are unique.
Access rules check out; it's any-any for LAN to VPN and vise versa on both appliances.
Route policies are in place for the Tunnel Interface on both appliances.
Zones for address objects check out fine.
Tunnel is up and green all the time.
The VPN configure is pretty generic. Different configures were tested by SonicWALL support that result in the same exact condition. Here is where the support left off -
Hi @MPan
I've reached out to our Support team, for an update, regarding your open cases.
Thanks for your patience, and let me know if you have any questions in the meantime.
Some thoughts, and I accept 'i dont know' as an answer.
What firmware does each device have? Have you tried doing the tunnel as Site-To-Site?
Using IKEv1 Main Mode? DH Group greater than 2? SHA256? IKE ID's as IP address? Keep-alive enabled on both sides?
BTW tunnel security recommendations are DH 14, AES256, SHA256 with a strong PSK.
Post your ticket #, get @MasterRoshi @Marco Octavian or @Micah involved.
@TKWITS, each appliance is now on the latest firmware.
TZ270 is on 7.0.1-5023-R1826
TZ350 is on 6.5.4.8-89n
Tried earlier firmware and it did not work either.
Tried Site-To-Site tunnel previously, same issue. Furthermore, out of three subnets behind Gen 6, only 1 random subnet may be ping-able at different times.
Tried IKEv1 Main Mode.
Tried DH Group 2, 5, 14.
Tried SHA256 and numerous other options.
Tried IP address as IKE ID.
Tried Keep-Alive Enable on either one or both.
Case# is 43780632.
@ENABEV,
Thank you for following up.
I just receive a reply from support after you reached out.
@MPan,
I am happy to help!
Hopefully your case gets resolved soon.
10/1, I talked to a SonicWALL's "senior" support tech this morning. After a Bomgar session that was a repeat of the previous sessions, the "senior" tech concluded that since the ICMP packet is consumed by the virtual private network tunnel but the packet does not show up on the packet capture of the destination device, therefore the ISP is the culprit and the ISP is blocking certain ports.
I was told by the "senior" tech that I need to "prove" that ISP is not blocking ICMP and ESP packets.
I'm incredulous, especially on ISP blocking the ICMP since I can ping the external interface of both Gen6 and Gen7 devices just fine. Tunnel is up and it's green.
I already confirm with the ISP previously that they do not block any ports, but since the "senior" tech states that we are in an "impasse", therefore I will request a packet capture with the ISP, if that is possible.
The "senior" tech also told me that SonicWALL will NOT replace any device unless there is a hardware issue, so if your device powers on and it does not show any hardware faults in the log, then you are out of luck.
May I ask who is your ISP? Do you have any other Sonicwalls out there to test a tunnel with?
Unfortunately it seems support is on hold since Sonicwall is up for sale...
@TKWITS,
G6 is on a Verizon FIOS circuit.
G7 is located in a WeWork building; it is using Verizon FIOS also.
Verizon does not block ICMP or ESP/IKE/IPSec. Do you get a direct hand-off from the WeWork building, or do they have a firewall in place?
@TKWITS,
WeWork provides a drop with public static IP; I have no visibility to their network. I have requested clarification, but WeWork previously stated that WeWork does not block any port.
I understand it is unlikely that either Verizon or WeWork is blocking ESP/IKE/IPSec, especially when tunnel interface is up and traffic is at least going in one direction or another (completely random).
SonicWALL support has declared an "impasse" and will not assist any further until the ISP runs packet capture to demonstrate no traffic is dropped.
Unfortunately, I do not have a spare VPN device; we usually purchase support contracts, instead of stocking spare devices.
@MASTERROSHI,
Thank you for your advice.
I took pcap on ESP/ICMP with "Monitor intermediate IPsec traffic" enabled on both Gen6 and Gen7 SNWL; first I took pcap when the pinging is working and then again when pinging is not working.
When pinging is working, there is no ICMP traffic between the two external interfaces; this does make sense since SNWL does not specific ICMP port is used for VPN. However, I do see ESP packet traffic from Gen6 to Gen7 and from Gen7 to Gen6.
Next I disable the tunnel interface, then re-enable the tunnel interface, and pinging no longer works; I can consistently break the pinging by doing this.
When pinging is not working, I see ESP packet from Gen6 to Gen7. On Gen7, I see Gen7 received, generated, and forward ESP packet to Gen6, but Gen6 does not receive any ESP packet Gen7.
Below is the pcap on Gen7 (.184) sending ESP packet to Gen6 (.146).
So in your opinion, Gen7's ISP (WeWork on Verizon) is the culprit?
Sounds like either the WeWork upstream firewall or ISP is touching the ESP traffic. Hopefully they don't have ESP ALG enabled (ugh) because it sounds like when you are manually renegotiating the tunnel and the SPI's change, this issue starts.
Technically, the GEN6 ISP/Modem might be at fault but you can rule that out by testing a tunnel to another location to see if it presents the same behavior.
@MASTERROSHI,
There is no issue with the Gen6 site. Tunnel interface works fine on the Gen6 with another Gen6(1).
I observe the same issue with Gen7 and Gen6(1).
OK, then you have narrowed it down enough to be the ISP or Upstream device at the WeWork location.