IBM Cloud Global

 View Only

vFSA on IBM Cloud: Part 3 Operational Administration and Maintenance

By Andrew Sloma posted Tue April 30, 2024 12:36 PM

  

vFSA on IBM Cloud: Part 3 Operational Administration and Maintenance

In part 1 we discussed the architecture for the new IBM Cloud Virtual Fortigate offering. In part 2 we discussed how to configure basic routing and firewall policies. In this third part we will discuss some maintenance related tips for keeping the vFSA firmware current and other best practices.

Allocating Additional IP’s

The vFSA comes with a public and private virtual IP that floats to the active node in the HA cluster during a failover. These IP’s are tied to this vFSA instance and out of the box are the only external facing IP’s. The vFSA can be used as a BGP, GRE, or IPSec endpoint. This requires configuring a reachable IP. Let’s say I want my vFSA to act as a public IPSec endpoint. The agg1 public IP that comes with the instance (We will call this the floating IP or FIP) is an IP I would be tempted to use. However, this can lead to some complications later in the lifecycle of the product. For example, if I want to migrate to a new vFSA I cannot move this IP to the new instance and assign to agg1. This means I have to “re-IP” both the IPSec peer and the new vFSA. This can lead to downtime. Additionally, if I need a block of public IP’s for assignment to various sub-interfaces the vFSA only provides the 1 FIP by default.

So, what’s the solution? Take advantage of secondary static subnets. IBM Cloud Classic lets me order a static subnet and then statically route it to the Gateway FIP. 

  • Select the datacenter that contains your vFSA.
  • Select the CIDR size for the block of Public IP’s you want to allocate. In this example /29.
  • Select the Routing option “Static”.
  • Expand the Destination Subnet that contains your vFSA FIP. In this example 163.69.66.248/29 and select the vFSA IP.
  • Select Create.

Great! We now have a block of public IP’s we can assign to our vFSA. If we ever want to redirect traffic destined for these IP’s to a new vFSA we can use the “Change route” option shown below.

Upgrading the vFSA firmware

The vFSA firmware can be upgraded or downgraded by using the native Fortinet Fabric Upgrade tool. This tool is owned and supported by Fortinet and can be found by logging in to the Fortigate Web Console and navigating to System > Firmware & Registration > Fabric Upgrade. The tool lists all available upgrade and downgrade versions. The tool will back up the current configuration by downloading it to your local system. It automatically restores the configuration as part of the firmware version change process. 

It is important to note that downgrading to version prior to v7.4.1 will cause cluster instability and will most likely require a full rebuild of the cluster as it will most likely be not usable.

In this example I will demonstrate the steps to upgrade from 7.4.1 to 7.4.2.

  • Login to the vFSA web management interface. Typically, available firmware updates will show up on the status page.

  • Navigate to System > Firmware & Registration > Fabric Upgrade
  • Select version to upgrade to, in this case 7.4.2. Schedule it. And proceed with the upgrade. A zip file will be downloaded to the local machine with a backup of the current configuration.
  • The upgrade takes around 5 to 10 minutes in my experience. When complete the dashboard will show the new firmware level.

It is also possible to enable automatic patch upgrades as part of the vFSA configuration. This removes the needs for the manual steps we walked through.

Sometimes a Gateway node needs to be OS reloaded due to a bad hardware component (such as a disk failure), a mis-configuration that corrupts the vFSA, or some other reason requiring a reset to defaults. In these cases the vFSA node needs to be running with a supported IBM Cloud version as discussed here. The Gateway Readiness check will determine what version is running and will determine what steps need to be taken to proceed with the OS Reload.

Changing the vFSA License

The vFSA is installed with the licensing that was purchased as a part of the new order process. This includes the option for 1G or 10G network bandwidth speeds and the ATP, UTM, and Enterprise licenses. IBM partnered with Fortinet to integrate these license entitlements into the FortiFlex licensing model. This allows customers to change the license running on their vFSA through the IBM Cloud Gateway details page. The 1G and 10G licensing cannot be changed, but in this example we will show how to upgrade from the 10G UTM license to the 10G Enterprise license from the IBM Cloud Gateway details page.

  • Navigate to your Gateway details page and run the readiness check by clicking Readiness check > Run Check > License update/renew. The readiness check ensures certain prerequisites are met before changing the license. These pre-req’s include connectivity to the vFSA and having a supported version in place.
  • Once the readiness check is successful, we can use the Details > Update License button to change from UTM to Enterprise.
  • The FortiFlex licensing running on FortiCloud will push the new license to both nodes in the cluster within a couple of minutes and the new billing will kick in immediately. You can see the license was applied to the vFSA below in the Dashboard > Status > Licenses section.

IBM Cloud billing is on a monthly basis so any license changes will be billed at the end of the month on a pro-rated basis. The tight integration between the IBM Cloud billing system and the Fortinet FortiFlex API makes licensing and billing flexible and easy to maintain.

Summary

I hope this blog series has been informative and useful as you explore the features provided by vFSA on IBM Cloud. Additionally, you can find more detailed documentation on the IBM Cloud documentation site.

Landed in the middle of this series? Start here: vFSA on IBM Cloud: Part 1 Architecture

0 comments
15 views

Permalink