I'm working on a proof of concept deploying a single instance of a Fortigate cloud image in Google cloud. How is one supposed to deploy and restore from a previously made backup?
Apparently one can put a backup in user-data metadata field, but that field has a limit of 256K, whereas the smallest backup is closer to 400K. Is there someway to strip that backup of defaults and other junk to maker it fit into 256K?
The only other options for automated restore are ftp (not even sftp) and cloud management console, do I really need to spin up a side VM with an ftp server in order to restore a backup?
The idea is that in production, an operator/admin configures a firewall via GUI or CLI and in case of an issue, he can simply rebuild using the known working backup. Availability is not a concern, we can live with a 5 minute outage.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Deploying and restoring a Fortigate instance in Google Cloud from a backup can be a bit challenging due to the limitations you've noted. The user-data metadata field's size limit indeed poses a restriction for direct backup restoration. Here's a potential approach:
When deploying a Fortigate instance in Google Cloud, the idea of using the user-data metadata field is enticing due to its simplicity, but the size constraint can be limiting. If the backup is slightly larger than 256K, it might be feasible to manually edit the backup to remove any unnecessary configurations or default settings. However, this can be risky as inadvertently removing a critical configuration could render the backup unusable or the firewall non-functional.
A more reliable method would be to use an auxiliary service for backup restoration. While the Fortigate cloud image might primarily support FTP for automated backup and restoration, using plain FTP in a cloud environment, especially for something as critical as a firewall configuration, isn't ideal due to its lack of encryption. To work around this, you could consider a two-step approach:
FTP Server on a Side VM: Deploy a lightweight VM in the same VPC or network as the Fortigate instance. This VM would host an FTP server. Upon Fortigate boot-up, a script or automated process can retrieve the backup from this FTP server and restore the configuration. This VM doesn't have to be always running; it can be initiated only when needed to minimize costs and potential security risks.
Automated Process: To streamline operations and ensure minimal intervention, automate the backup retrieval and restoration process. When the Fortigate instance starts, it could automatically reach out to the FTP server to grab the latest backup and restore its configuration. This ensures that if there's ever an issue, the firewall can be quickly re-deployed using a known good configuration.
In a production environment where an operator or admin is responsible for the firewall's configuration via the GUI or CLI, having an automated backup and restoration process is crucial. By leveraging an auxiliary FTP server VM and automating the backup retrieval and restoration, you can achieve a seamless, repeatable process for deploying and restoring Fortigate instances in Google Cloud, ensuring you can recover swiftly even if there's a configuration mishap.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1732 | |
1105 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.