TZ670 Random Reboot on 5095
On 12/17/22 I updated my TZ670 to 5095 from 5080. I have been on 5080 since 10/10/22.
While on 5080 I did not have the setting enabled to save logs to the secondary storage. I previously disabled this since there was a random reboot issue on an earlier firmware that I thought was fixed (issue with 5018).
After updating to 5095 I enabled the setting to save the logs to the secondary storage.
This morning 12/19/22 around 48 hours after the update to 5095 the TZ670 rebooted. I am not sure why. Once back into the TZ670, I went ahead and disabled the option to save the logs to secondary storage and will monitor it.
I do not have a lot of users. I use this at my home. Alos, I was logged in via SSLVPN when this reboot happened and first noticed an issue when my vpn was disconnected. SSLVPN has been solid with 5080. After the TZ670 rebooted, I was able to VPN in again. A few minutes later I lost VPN and was able to VPN in again a few minutes later but that second loss of VPN was not a reboot issue. This second loss of VPN was a few minutes after disabling he save logs to secondary storage. Not sure if related.
Anyone seen this recently? A random reboot?
Sonicwall Support would need to check the diagnostic logs to see the cause for the reboot.
Please collect the following items from the firewall:
Tech Support Report
Firewall Logs ( show all entries and downloaded in CSV Format ),
How can I download required tech support files (TSR, settings, GUI logs, trace logs)? | SonicWall
After getting these, please contact the technical support team to help identify and resolve this reboot:
Contact Support - SonicWall
Chiming in here: Saturday morning, doing some routine, unplanned work, and oops! I've got no internet.
Turns out my TZ270W (SonicOS 7.0.1-5095-R3599) rebooted on its own.
First time I've noticed, and now I'm curious to know how to track down previous reboots....
note since I disabled the external memory I have not seen another reboot. Not sure if that is related or not. Do you have external memory.
I have also noticed more disconnects when connected via SSL VPN than I did previously. I connect when I am working at another office just to protect my traffic.
@Rinconmike - no external memory in a TZ270W and was not using SSL VPN. It just up and restarted on its own.
Case opened with all the supporting documentation (felt bad that the tech wanted a fresh copy of the log despite knowing the case was about a reboot - because we know it has no information at that point about preceding conditions).
Waiting to hear back.
Well got another random reboot of my TZ670 this morning.
Time to get logs from the console port.
@TKWITS - you know, I never - ever - want to do that...
This past weekend, no Wi-Fi and the UI was locked. Had to hard boot it. Because I have an NFR device, I'm only allowed 8x5 support, so couldn't even call it in.
But, I now have a hotfix that is supposed to curtail this (not very pleasant) behavior. I am going to have to run it for a few weeks to find out if it works.
Another thing to note - On the Gen7 firewalls, on the TSR page, there is an option to download the "systemlogs" this would include all information need for support to investigate a reboot issue. The console file and core dumps are part of this systemlogs file and are important for troubleshooting the issue.
If you are still experiencing a reboot, please download this systemlog and contact our support team to get this looked at ASAP.
Interesting that you suggested this.
On one client TZ670 that I recently deployed, and which rebooted without warning (thankfully at 8:30 pm) this utility got hung up and I couldn't access the GUI for at least 20 minutes. The gz/tar file never was generated.
And before you ask, I can't possibly submit a Support Case by saying I can't provide the file they require...
just got another reboot. Will open a support case.
@Rinconmike - A question for you.
If you go to Device - Diagnostics - Tech Support Report and click on the Download Systems Logs button, does it work?
yes. I submitted that.
Could you check the diag page to see if there was a core dump generated for that date?
Let me know!
@TonyA - on my TZ270W that locked up on its own and I had to hard boot to start there is no Core Dump file available.
For the client's TZ670 that rebooted arbitrarily (and for which a case is open) yes, there was:
The CSR pulled it last week.
@Larry Thanks for the update on that.
For your TZ270W - was just a lock up or a reboot (Firewall rebooted on its own)? You will only see it generated for a reboot.
@TonyA - in January my TZ270w device rebooted on its own. In February it locked up and required me to pull the plug. Can't wait to see what happens next month...
In the middle of a Lenovo Teams meeting presentation my TZ270W decided to reboot. No Core dump file shown in diagnostics.
Case 44141281 was "pending close" with the note that this problem is supposed to be fixed in the next firmware release.
That day won't come soon enough!
Support has not been any help for me.
Had another reboot 2/21. I sent support all the files they asked for. To include a core dump that was a 1kb file.
Received a note from the CSR regarding my frequently incapacitated TZ270W yesterday:
I went through the logs and I was not able to find any stack trace related to the reboot in the console logs and also the core dump is not generated, the logs are not showing it and it may have just been a spike in traffic at that time or an outage on the ISP side but now it's no longer happening we can't fully know if it was ISP or SW, I would like to ask you to force reboot this device or do a safe downgrade to the lower build and monitor I would recommend you to wait on the lower firmware until the other is released/more stable, please reach out to us if you have any similar issues after a safe downgrade.
So I spend a few hours on remote session and repeatedly providing logs and they show nothing? That there is an ISP problem? And I should continue to wait for a 7.0.x update (while everyone is heads-down coding 7.1.x)? Sure, thing - a reboot will fix this!
As for the TZ670 that rebooted on its own and for which there was a core dump, I have been asked - several times - to supply the System Logs. Unfortunately, I cannot do that because the device simply times out with a Network Error (OK) message.
I have just requested an RMA for that device because I have been unable to obtain System Logs since the incident was first reported a month ago - only two weeks after deployment.
Quite a discouraging way to start a new year (about as politely as I can express things in a vendor-governed forum).
I wonder if these reboots have anything to do with the notice Sonicwall just put out.
@TKWITS I was going to install the new firmware later today to find out if it fixed this problem.
I just got another random reboot. Anyone try the 7.0.1-5111?
I updated to 7.0.1-5111 and will post if I get any reboots. This one took longer that others to update.
@Rinconmike I was under the same impression that the update took longer as usual, whopping 10 minutes for a TZ 470, that requires some patience when done remotely :)
I didn't time my TZ270W but it was longer than I anticipated.
OTOH I just updated two client TZ600's and was remotely connected to each server. It took one minute for the remote connection to dissolve, but only 5 more minutes before the session was restored and I was able to access the firewall. Faster than expected.
on my case with 5095, support noted per the logs, the "Firewall Reboot is due to DP-engine similar to issue reported on GEN7-37134, this has been fixed on latest version 7.0.1-5111 version"
The 5111 Release Notes lists GEN7-37134:
"GEN7-37134 Under some conditions, the Content Filtering Service (CFS) DNS reply handling and request time can trigger conflicts in the handling of cache timers, causing the device to restart."
One week after installing 5111 on a client's TZ670, the device rebooted in the middle of the night. My RMM took the "device offline" alert and generated a ticket (which auto-closed after the reboot completed).
I'm getting quite frustrated about this, because if it hits during the day, the resulting outage is going to impact operations.
Worse still is my inability to download the System Logs which might point to what the problem is. Oh, yeah, there's an open ticket for that now, too.
@Larry it's weird that you cannot download the Trace Logs etc. from the Internal settings, but if nothing helps I would consider attaching something to the serial console, that helped me in the past to catch some information while crashing.
@BWC - I can get to the internal diagnostics page just fine to download the trace logs. What does not work - on two TZ670s that were NOT migrated - is Device = Diagnostics = Tech Support Report - Download Systems Logs button. That ends, after about 5 minutes, with a Network Error message and no .tar.zst.gpg file created.