feature request - firewall config backup and restore

Comments

52 comments

  • Avatar
    Ross

    @Firewalla - what is the status of your work? I am lost after such a long conversation with so many topics and want to make sure I add correct thoughts on current information, not some long-forgotten comment.

    2
    Comment actions Permalink
  • Avatar
    AzagraMac

    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.

    2
    Comment actions Permalink
  • Avatar
    Aaron

    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.

    2
    Comment actions Permalink
  • Avatar
    timt

    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.

    2
    Comment actions Permalink
  • Avatar
    Ross

    So nothing new is planned?

    1
    Comment actions Permalink
  • Avatar
    Network Bat

    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.

    2
    Comment actions Permalink
  • Avatar
    Kurtis Bickhaus

    Surely there is a way to export the configuration, even if we had to encrypt it, there is a way to do it WITHOUT exposing anything proprietary. Perhaps that’s the concern? I mean, if it is, why not just say so?

    1
    Comment actions Permalink
  • Avatar
    Firewalla

    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. 

    0
    Comment actions Permalink
  • Avatar
    Kurtis Bickhaus

    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.".

    2
    Comment actions Permalink
  • Avatar
    Mstormo

    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.

    3
    Comment actions Permalink
  • Avatar
    Kurtis Bickhaus

    That’s also a wonderful idea to add onto what I said about taking a full image along with the config. I would not mind at all adding a firewalla folder to my inventory with versions and configurations.

    2
    Comment actions Permalink
  • Avatar
    Aaron

    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.

    1
    Comment actions Permalink
  • Avatar
    Anthony Domagas

    Just lost all of my target list and including the default target list.

    Add my vote for the ability to externally save and restore configs

    2
    Comment actions Permalink
  • Avatar
    Harry Kemp

    +1 for the ability to backup and restore a config file. Especially useful for new users like myself who might break something early on.

    2
    Comment actions Permalink
  • Avatar
    Markus Karlseder

    +1 absolute standard main function as every device can break.

    please give us a simple import / export config-file

    2
    Comment actions Permalink
  • Avatar
    Bob O'Hara

    +1 It would be really nice if it was also human readable, say XML encoded.

    1
    Comment actions Permalink
  • Avatar
    Sebastien Carpentier

    +1... Definitely a much needed functionality. Should not be hard to compress/encrypt and export the config... Am I underestimating it?

    1
    Comment actions Permalink
  • Avatar
    Michael Turchin

    If the last successful config is saved in the app, what about allowing import/export of that config file from the app?

    1
    Comment actions Permalink
  • Avatar
    Ross

    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.

    0
    Comment actions Permalink
  • Avatar
    Firewalla

    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.

    0
    Comment actions Permalink
  • Avatar
    Kurtis Bickhaus

    We just need “developer mode” then. Let some of us who know what we’re doing break some things, and just leave a proper warning. Do something smart to enable it, like the early release fast-tapping to enroll. Make it super clear that it’s not to be screwed with.

    0
    Comment actions Permalink
  • Avatar
    Ross

    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?

    0
    Comment actions Permalink

Please sign in to leave a comment.