Short Answer: NO, please don't.
Recently, the NSA (National Security Agency) recommended that users reboot their routers once a week. This is a valid "best practice" for standard consumer routers. (References: Best Practices for Securing Your Home Network, National Security Agency; NSA Warning—Reboot Your Internet Router Now, forbes.com).
Consumer routers often have a reputation for needing reboots because their software is less stable or slower to receive updates. Rebooting is an easy way to fix issues like memory leaks and bugs, and is a blanket safety net for the average consumer router. While this may not be true for all vendors, it is a common concern behind this recommendation.
However, Firewalla is different. It is a dedicated Intrusion Prevention System (IPS) modeled after enterprise routers and data center networking gear, meaning routine rebooting is not required. It isn't necessary for "digital hygiene" in the same way as a smartphone or a budget Wi-Fi router. In fact, we do not recommend rebooting Firewalla unless there is a specific issue or reason to do so.
Stability and Security Go Hand in Hand:
Firewalla's software architecture is modeled after enterprise-grade equipment. Instead of using common consumer router firmware (OpenWRT-based Linux), Firewalla uses Ubuntu as a base, the same operating system that runs the "cloud." Not only is Ubuntu more stable, but it also inherits some of the "goodness" of its security baseline from data center usage.
Firewalla software is based on Ubuntu, a Linux distribution that runs enterprise data centers.
Firewalla software, by design, is not to reboot and can self-protect if things go wrong.
Built-in health checks and watchdogs detect and recover from issues automatically, without needing a reboot. (Similar to other enterprise-grade software.)
(This is one of our older units ... up 1568 days uptime.)
Reboot to Update?
Firewalla is engineered to be updated without rebooting and with minimal interruption to your network traffic. All updates are automatic and mandatory. This will guarantee any potential issues are fixed without delay.
Reboot to Remove Threats (Persistent Bad Code)?
Being a security device at heart, Firewalla is designed to protect itself from intrusions, including:
- Blocking unauthorized inbound access (Ingress Firewall)
- Monitoring and alerting on suspicious behavior (Active Protect)
- Providing visibility into network activity and attacks
Please make sure you do not remove Firewalla's recommended configurations, such as the Ingress Firewall, Active Protect, etc.
With automatic updates, IDS/IPS/Firewall, and self-monitoring, using Ubuntu, it will be very hard for attackers to persist malware in memory.
Will a Reboot Ever Be Needed?
We do not recommend rebooting the unit unless absolutely necessary (for example, if your Firewalla has no Internet and you cannot connect to the box via the local network or Bluetooth). If you're experiencing any issues with your Firewalla, please contact our Support Team at help@firewalla.com.
Where is the Security?
For better security, Firewalla will need to "remember" the past and retain short-term memory of moments ago (similar to the human brain). Based on this large set of memory, Firewalla can identify behavior-based events.
Short-term memory includes:
Your actions on system alarms (e.g., mute, allow, or block)
Recent interesting flows
Gathered statistical data
When you reboot the unit, Firewalla will lose some of its short-term memory. It will need to accumulate short-term interactions with you again (such as your interactions with recent alarms, flows, DNS requests, and blocks).
When this memory is lost, the system will become less efficient and will need more time to re-learn "normal" behavior for your devices.
Comments
2 comments
I've been struggling with intermittent network issues on certain devices making certain kinds of requests for weeks now, and I spent countless hours trying to troubleshoot it and not getting anywhere. In a fit of frustration, I decided to reboot the Firewalla via the software, and lo and behold, everything started working properly again.
I've been struggling with intermittent network issues on certain devices for weeks now, and I spent countless hours trying to troubleshoot it and not getting anywhere. In a fit of frustration, I decided to reboot the Firewalla via the software, and lo and behold, everything started working properly again.
Firewalla is a very stable and excellent product, but it is past time for it to have a scheduled reboot function.
Agreed with Jason. We manage Firewallas at client offices and we do run into occasional instability. When that happens, a reboot has been the only thing that has reliably brought the box back to normal.
The part that matters from an MSP seat: when the firewall goes sideways, it takes the VoIP system and everything else with it. For a business that needs phones and internet to operate, spending days going back and forth on troubleshooting isn't viable when a two-minute reboot restores service immediately. We are not asking for a weekly scheduled reboot as a maintenance habit. We are asking for the ability to trigger a reboot, or schedule a one-time reboot, from the MSP portal so we can restore a client without dispatching someone or waiting on a support cycle.
Two suggestions that would make this work for both sides:
1. Put an option on the reboot dialog to capture and upload a diagnostic bundle to support before the unit goes down. Right now the tradeoff is backwards. We reboot to save the client, and in doing so we destroy the state that support would need to find root cause. If the box collected logs, process state, memory and interface stats at the moment of failure and pushed them up before restarting, you'd get better data than you get today from a ticket opened after the fact, and we'd get our client back online. Same option on a scheduled reboot.
2. Persist the short-term memory to disk before a graceful reboot and reload it on boot. The article makes a fair point that a reboot costs the box its recent alarm interactions, flows and statistics, and that it takes time to re-learn normal behavior. But that only applies to an ungraceful restart. If the reboot is initiated by the admin, the system knows it's going down and has time to flush that state and pick it back up when it comes online. That would remove the main argument against rebooting entirely.
Root cause still matters, and I'd expect the backend logs to be there for support to review so the underlying issue actually gets fixed. But "don't reboot" isn't a workable answer when a client is down.
Please sign in to leave a comment.