feature request - firewall config backup and restore
yesterday, blue went out for the 1st time. after reading up on how to recover, the reflash worked and i had to pair and update the device names and rules again.
a way to download the config and use the same config to update a new firewalla would be nice. i mean, if you got a quite a few devices like IoT that will each have to be renamed in the device list, and rules recreated or approved again, a config file would make recovery easier.
-
More than 3 year of ticket, and still no possibility to export the configuration to a file, how embarrassing....
We don't just want the option to migrate, which is fine, even the worst router, you can export the configuration.
The truth is that Firewalla leaves much to be desired, it is more worthwhile to mount a Pfsense on a medium powerful computer with 2.5g and 10g cards, than to continue investing in firewalla.
One that says goodbye.
-
I'm in complete agreement with the folks requesting the ability to backup/restore a system config. I know there's the current config in the app, but why not provide the ability to export/restore the config via the web interface, or ssh console? Taking a backup is standard before any work and trusting/hoping a known good copy is in the app on someone's phone just doesn't cut it.
-
Just wanted to add my vote for the ability to externally save all configs and restore them.
My use case, which has been described by someone else already in this thread, is that I want to "baseline" my Firewalla Gold and have a way to restore to those configs at any time. I want to have multiple "restore points" so that, as I make changes, I can always revert to any of those "restore points". I'd prefer to store the configs myself, but if they need to be stored in a place that is managed by the app or by Firewalla, that is ok, as long as the configs can be applied to a new Firewalla as well.
I would want the config backup file to be downloadable from the web based interface (my.firewalla.com) so that I can save the config files on my network internally.
I've also wanted the ability to turn off automatic upgrades because I run a business and I want to lower the risk that anything might break Firewalla. One of the updates broke local DNS hostname resolution, and it took down my network for a while. I reported the issue, and Firewalla fixed it within a few days, but during that time, I had to scramble to get my network back up and running. I want to be able to "version lock" my Firewalla and mobile app, and I know that this is not easy to implement.
I know that there's a lot of challenges with adding these features. For one, the Firewalla and the mobile app need to remain compatible with each other. Turning off automatic upgrades could result in a user upgrading their mobile app while having an incompatibly older version of the firmware/software on their Firewalla. As for "restore points" or backups of all configs, this is tough because Firewalla is, in fact, Ubuntu with lots of apps installed that support all of its features. The configs for each app would need to be included in the backup file. And, because Firewalla performs automatic upgrades, there would need to be a degree of backward compatibility with backup configs for older versions of Firewalla. Backward compatibility of old backup config files is not an easy thing to implement. They would probably have to come up with their own config file schema that is an abstraction of all of the configs for the apps on Firewalla. It should also be noted that Firewalla has their own backend to support many features, and their backend has to also be compatible with the mobile app and software running on the Firewallas. I know that their backend probably mostly proxies API requests from the web and mobile client to the Firewalla device, but nevertheless, their backend support is free to us as users, which is pretty nice, and it adds some complexity for the features we are wanting.
Another feature I've wanted is the ability to give servers on my local network additional hostname aliases. Even my Fios router supports this through their web UI. For Firewalla, it looks like I'm going to need to add DNSMasq configs. If I have to SSH into my Firewalla to manually add DNS configs just to support this, I might as well switch to something that gives me more control. I've tried using a DNS server on my local network, but that put me down a rabbit hole that was taking way too long.
Firewalla has been great, and the integration of their mobile app is really nice. The mobile app notifications are another big reason I've stayed with Firewalla. However, I am thinking I'm going to need to switch to pfSense. I'm not going to like having to VPN into my network to view and modify firewall configs with the pfSense web UI, but pfSense gives me a lot more control. Firewalla doesn't seem well-suited for businesses that need more control over configs and the ability to schedule and test software upgardes before they are applied in production. And to be fair, I do not think Firewalla claims to be for more than home/personal use or small businesses with simpler networking needs.
Overall great product, but I guess it's back to the drawing board for me.
-
Yea, this is a bit ridiculous. For example, tonight I need to test a bunch of changes and I want to know for sure that I have a simple way to roll back at a moment's notice.
In theory, this should be as simple as just hitting a "Export system settings", and as easy to restore as "Restore system settings from file"
I won't begin to venture as to how easy this is to implement, but in terms of "10 things every piece of network equipment should have", this is in the top 10 list from day one.
-
First, there is a stored configuration already, in case you reset the unit.
As for storing multiple versions of the configuration, the issue is really maintaining the configuration itself. If you keep 10 versions of configuration,the software needs to ensure all that 10 versions can be activated; if there is anything significantly changed in the past, then the complexity of keeping things compatible will increase significantly. If you are with us for the past few years, there is always a significant change between releases, and with that, configuration schema also changes.
-
I suppose then, it might be an advanced feature that some of us are willing to work with. I understand that perhaps along with the config backup, we might need to also back up a copy of the whole system to flash back to the version that worked at the time of backup. Perhaps a "developer mode"? It would be fitting seeing as you have alpha and beta already. Plus the upcoming API. I myself am certainly willing to have to go through the extra effort of sticking an OS copy along with the backup. It truly is just as critical as any other machine.
*Or heck, call it something scary like "Warning, Administrative Mode: For qualified network technicians only. Misuse may result in system corruption.".
-
This is really too "consumer" thinking, and not geared towards us "Home DIYers", "Advanced Tinkerers", "IT professionals" who don't mind things getting a bit more advanced.
Configurations can change, sure, then just version the configuration when you save it, and mark it as incompatible in the new firmware when you no longer can read it. Heck, I'm sure there are portions you could still read, even if sections are not valid anymore. You could even use the readable sections as a template for proper values if we have to go through a new setup routine. "It might break" is simply a very lame excuse for not allowing downloading our settings.
- I might want to experiment with a completely new network configuration with VLAN etc, only to quickly revert if it didn't work out or my family starts complaining. Storing my settings locally would let me quickly recover to the old configuration
- I had a water leak a few years ago, which fried every single piece of electronics in my house (except my laptops). Having a off-device backup would allow me to recover quickly. On-device configuration would be useless.
- Maybe I would want to replicate my current setup at my parents house, using my on configuration as a template.
There are tons of reasons to offload the configuration to somewhere else (heck, I'd like to version control mine!). "You might not be able to load it again" is a cop-out, and unprofessional.
-
Agreed, @Mstormo. For a consumer box, this is fine, maybe even great, but for a lot of folks looking to develop and do more with it, the backup/restore issue is a non-starter. Most folks got around the problem with old configs was a long time ago, by not allowing incompatible configurations to be restored. There are a number of enhancements I'd like to try, but there's no way I'm going to risk breaking something and having to start over from scratch (which may very well be possible considering the one stored copy in the app may very well update before issues popped up). I wanted another Gold for my office network, but for now, I think I'm going to continue looking at other options.
-
While I agree with this idea, I would like the choice of restoring from any point a backup was saved and is now available (like in Apple's Timeline app) in case the last backup is not good enough to undo the problem. I may need to go farther back in time.
I realize that you do not have unlimited storage space available in the app, but it would be great to explore what other options you have if you open up the app to restore previously saved backups that are now available perhaps from the MSP interface or the phone's storage. This would shift the responsibility of archival of long-term backups to the MSP and/or consumer. You can continue to make it easy on the consumer by making a limited selection of backups (say the last 5) available for restore.
-
Not sure if I explained this before. The issue with storing multiple configurations is not related to storage. It is more of handling schema changes.
With each release, we modify how configuration is stored in the system. (adding new features, optimizing old features). This means the schema used for versions A, will be different than version B. If different versions of configurations are allowed, then there will be a significant (very significant) effort to translate the schemas. So, even if we add support for multiple configurations, it will need to be restricted. (meaning, you can't use a saved configuration from a different release)
We are thinking ...
The MSP is a special case, where the schema is stored in the cloud, so it may be easier to implement this.
-
Sorry if this is a dumb question, but it comes from a system architectural viewpoint and not a developer POV, Is it possible to backup without being so dependent on the underlying schema? Or what if you did not change the schema with every release but reserved if for when features are added or removed?
-
@firewalla - Security 101 is Confidentially, Integrity, and Availability. If you fail on any your device is not secure.
As it stands now this device has no workable backup solution. If my config becomes corrupted, the corruption is backed up. If I muck up my config, there is no rollback.
As designed, firewalla does not meet the basic security requirements of integrity and availability.
I should have verified this myself before purchase, but quite frankly it never occurred to me that a $400 router (purple) in 2022 might lack such a rudimentary feature.
-
@Firewalla: I don't think anyone here has an issue with incompatibility between box versions. The bigger brands like Fortinet, Palo Alto etc have largely the same caveats. I wouldn't mind a large warning that version changes invalidate the previous backups. Because that is exactly how it works with a lot of other brands. It would, however, be very convenient to have a quick restore point when you've made a configuration doodoo and you quickly need to revert. Or worse: you've made several changes over multiple days and you decide it's not working as you want it to. That's why that config backup holds so much value. The migration feature isn't really useable in these cases, if I'm right? Differences between box versions (and thus backup files) would be no deal breaker for me (and others, if I'm understanding it correctly).
-
@tettezak I am totally agree with you and all other brands including even small and home use devices has that challenges of upgrade and still having that back-up config feature. No need for deep detailed justification to explain why this request is simple :)
The question to @firewalla why this is difficult?
You are into software industry and config back-up and restore is one or the ABC application/hardware development.
-
Here's how I see it. Simple.
My Firewalla updates to new firmware all the time, automatically. Alas, there's a migration path from the previous configuration to the current configuration.
The backup feature would simply store the current configuration for the current firmware to a given location.
AND the backup feature should be configurable to automatically store the new configuration (using a new name, firmware/timestamped) to the same location after a new firmware has been applied and the Firewalla rebooted.
The backup/restore feature could then be set to only accept configurations compatible for the current firmware, which is fine, since you already have a backup for all the versions.
That way, you can store a configuration any time you'd like, manually. And every time a new firmware is applied, it's stored automatically. Done!
Locations could, for example, be any/multiple number of the following:
- USB stick in Firewalla unit
- Google account
- Microsoft account
- Dropbox
- Box.com
- S3/Azure BLOB/GCP blob storage
- FTP/SCP/SMB/NFS
-
@Mstormo nailed it. This could be implemented without any need to translate the config to human readable and back (like the big boys do).
You said, "The backup feature would simply store the current configuration for the current firmware to a given location"
Easy to do, and very simple. But it doesn't even require that level of sophistication. Popup a warning that says "This backup requires FW Vx.xx. You are running Vy.yy. Please visit firewalla.com to download archived versions of FW."
From there it might require the user to walk the upgrade tree so that each successive config schema change was applied in order. But that is still better than "Good luck! Hope you never crash!!"
Honestly, until I've never owned a piece of networking gear that could not be backed up. Even the lowly Netgear Orbi RBR50 can import/export a config as a non-readable bin file. -
I am new to Firewalla, and SHOCKED to see that there's no way to download/backup the configuration file. Heck, my $89 Hubitat home automation hub has automatic nightly backups to their cloud. OPNsense let me setup a google drive API call to do nightly config backups. My Ruckus Wifi APs let me download the config database....need I go on?
This is basic IT security 101....CIA. Confidentiality, Integrity, availability. Firewalla is severely lacking in "A"vailability. I don't understand how this isn't a basic feature.
I would propose two backup methods:
1) Allow the downloading of the config database to a local file that could be restored from (given same firmware version). Not ideal, but hey, WAY better than what we have now which is NOTHING.
2) Allow S3 compatible storage bucket to be used for automated nightly backups. S3 does NOT mean only Amazon. Wasabi, and many other providers have a S3 API interface.
-
We’re offered beta and alpha with no fallback. I’ve lost boxes multiple times testing, and they never restore properly. Why bother testing if we can’t even back up and restore properly? Just let us export… even without testing software, there’s no integrity. “Back up to another device.” K. These are mobile devices, they have a high likelihood high impact in regards to damage.
Please sign in to leave a comment.
Comments
83 comments