Deployment

FortiGate Deployment (HA Single Zone)

In order to deploy the FortiGate appliance in HA mode (Active/Passive), select this offering in the catalog.

You'll be presented with a set of parameters that you must specify to correctly deploy and configure the appliances. An IBM Cloud® Schematics workspace will be created automatically to run a Terraform script.

Here is the list of the parameters:

See below the set of parameters as presented in the UI for the Schematics workspace.

Fortigate appliances description

Once the deployment of the FortiGate appliances is complete, you can see two new Virtual Servers for VPCs deployed into the IBM Cloud VPC where the first one is the active and the second one the passive. You should see something like this

In the Networking tab you should see the list of the VNIs that have been created for each Fortigate. Each of these VNIs corresponds to a “physical” interface on Fortigate.

Port 1 is the management port, not used for any kind of traffic inspection. A {{site.data.keyword.fip_is_short}} address is assigned so the Fortigate can be reached via internet (this can be deleted in a later stage)

Port 2 is for the internal traffic. The IP address of this VNI will be the IP address of the next hop configured on the IBM Cloud VPC routes

Port 3 is a dedicated port for Heartbeat for the High Availability. See the Fortinet documentation: https://docs.fortinet.com/document/fortigate/7.6.5/administration-guide/849059/ha-heartbeat-interface

Port 4 is dedicated to the HA Reserved Management Interface. This interface allows direct management access to each unit in the cluster using separate IP addresses by reserving a specific management port within the HA configuration. For more details, refer to the Fortinet documentation: https://community.fortinet.com/t5/FortiGate/Technical-Tip-HA-Reserved-Management-Interface/ta-p/190132

The two interfaces with assigned public IP addresses should be protected by leveraging either IBM Cloud VPC Security Groups or the vFSA trusthost capability to enforce access controls (see: https://docs.fortinet.com/document/fortigate/6.4.0/hardening-your-fortigate/582009/system-administrator-best-practices)

It should be considered that each Virtual Servers for VPC in IBM Cloud IBM Cloud VPC supports a maximum of five virtual network interfaces (VNIs). Moreover, the instance's aggregate network throughput is evenly apportioned across all attached VNIs; consequently, dedicating interfaces to management and HA heartbeat traffic, both typically low bandwidth, can reduce the effective headroom available to data plane interfaces. Both constraints can be solved by selecting IBM Cloud VPC Gen 4 profiles, which provide enhanced networking characteristics (see: https://cloud.ibm.com/docs/vpc?topic=vpc-general-purpose-vsi-profiles-gen4-intel&interface=ui).

See here the configuration for the High Availability:

Initiate the Fortigate

Open the VNC Console on each of the Fortigate Virtual Servers for VPC and login as admin. The password to login the first time is the Virtual Servers for VPC ID as shown in the screenshot.

Configure a static IP address on the management interface and setup a default static route to access the Fortigate. See the FortiGate documentation: https://docs.fortinet.com/document/fortigate-private-cloud/7.6.0/vmware-esxi-administration-guide/615472/configuring-port-1

In our case we have (on the active instance):

edit port1
set mode static
set ip 10.0.0.10 255.255.255.0
next
end

config router static
edit 1
set device port1
set gateway 10.0.0.1
next
end

This should be configured on both the active and passive Fortigate.

Access FortiGate through the public IP address (the {{site.data.keyword.fip_is_short}} address for the Management port).

At the very first login, you are asked to apply for the license; please follow the procedure as described in the Fortinet documentation (you’ll be requested to reboot the two appliances during the process)

https://docs.fortinet.com/document/fortigate-private-cloud/7.6.0/vmware-esxi-administration-guide/299485/uploading-the-fortigate-vm-license

Once the license is applied, you can check the High Availability is already configured, you should see something like this in the UI:

Add a dedicated interface for public connectivity

To access the workloads on IBM Cloud VPCs via internet (via the Public Address Range), we have created a dedicated interface for it, the port 5. We need to assign an IP address in the subnet transit-eu1-public both on the VNI like in this screenshot (in our case the IP is 10.0.4.10):

And on the interface (port5) in Fortigate, like this

Please note this should be done for both the Active and Passive appliances.

Create a Public Address Range subnet and route the public traffic

A Public Address Range (PAR) is a contiguous set of public IPs that you can reserve and bind to a IBM Cloud VPC in an availability zone.

These IPs can be routed through FortiGate by simply configuring a public ingress routing to send the destination IP range to a FortiGate next-hop (in our case the IP of the port 5 on Fortigate). Response traffic from the target retains the original source IP as it exits the IBM Cloud VPC, ensuring that return traffic isn't dropped.

Here the creation of the Public Address Range, to be bound to the transit-vpc in the zone eu-de-1

As the PAR creation is completed, you should see something like this:

We need to create the route for this VPC:

Go to the Route, select the IBM Cloud VPC transit-vpc and create a new Route

Select Public Internet as Traffic Source

And finally configure the route by specifying as Destination CIDR the PAR just created and has Next-hop the IP address of the interface on Fortigate dedicated to the public access (port 5)

As everything is completed you should see something like this

Moreover, in order to allow outbound connectivity from the spoke Virtual Servers for VPCs to internet, we have to add a new route into the route table for the Transit Gateway.

Select the route table that has the Transit Gateway as Traffic source

And configure the default route like this

You should see these routes in your routing table:

You can check that this route has been advertised into the Transit Gateway (run a new Generate report):

The last step is to configure the route for the routing table for the traffic having source the Direct Link.

Once selected, setup the route for the Spoke IBM Cloud VPCs to be routed through the Port 2 on the FortiGate (IP 10.0.1.10). You should see something like this:

Enabling spoofing

If IBM Cloud VPC routes are configured to use a FortiGate interface as the next hop, IP spoofing needs to be enabled on that interface so that it can forward traffic correctly.

In our case it should be enabled on port 2 and port 5; see this example.

Configure the static routes on Fortigate

In order to allow traffic inside and outside the Transit IBM Cloud VPC, we have to configure the static routes for the internal traffic (port 2) where the gateway is the gateway of the subnet for the IP of the "traffic" port (port2). In our case the gateway IP is 10.0.1.1.

The Destination subnets are all the subnets to be connected inside the Cloud and to subnets connected via VPN and Direct Link.

We also need to setup the default route for the port 5, where the traffic from/to internet to the internal network should happen.

Configure the firewall policy

As very first configuration, we create a firewall policy that allows any traffic that has as source and destination the port 2, for the internal traffic. You should have something like this.

Notice the Implicit Deny policy is created by default once the FortiGate is deployed.

Tutorial, testing connectivity

This section describes the connectivity test to validate the various use cases.

From server connected via the VPN to Spokes and vice versa

In order to test the connectivity between the Virtual Servers for VPCs into the Spoke IBM Cloud VPCs and the remote servers connected via the VPN tunnel, login into this server and ping the Virtual Servers for VPC. You should see the ping is successful like this.

The outbound connectivity can be tested by pinging the remote server from the Virtual Servers for VPC in one of the spoke IBM Cloud VPCs. You should see the ping is successful like this:

From Power (DL) to Spokes and vice versa

In order to test the connectivity between the Virtual Servers for VPCs into the spoke IBM Cloud VPCs and the remote servers connected via the Direct Link, login into the Power Virtual Server Virtual Servers for VPC and ping the Virtual Servers for VPC. You should see the ping is successful like this.

Please note that, if the Power Virtual Server is connected to a public network with a second interface, its default route is configured to use this interface. This means that we need to add a static route in the Power Virtual Server to route the traffic to the IBM Cloud VPC Spoke Virtual Servers for VPCs through the private network. You should see something like this:

Where all the 10.0.0.0/8 subnet (that includes all the subnets in the Spoke IBM Cloud VPCs) is routed via the gateway on the private interface env3.

We can test also we can ping the Power Virtual Server Virtual Servers for VPC from one of the Virtual Servers for VPCs in the Spoke IBM Cloud VPCs.

From Spoke 1 to Spoke 2

In order to test the connectivity between the Virtual Servers for VPCs into the spoke IBM Cloud VPCs, login into the Virtual Servers for VPC in one spoke IBM Cloud VPC and ping the other spoke IBM Cloud VPC . You should see the ping is successful.

From Internet to Spoke Virtual Servers for VPCs and from Spoke Virtual Servers for VPCs to internet

In order to enable access to one of the Virtual Servers for VPC into the spoke IBM Cloud VPCs from internet and also to allow the Virtual Servers for VPC to access some services on internet, we have to do some additional configuration in FortiGate.

Here are the steps to allow inbound connectivity:

Create a Virtual IP that maps one of the IP addresses in the Public Address Range to the private IP address of the Virtual Servers for VPC. The interface where the "translation" happens is the interface dedicated to the public traffic (port 5)

Create a Firewall Policy that allows traffic from port 5 to port 2. The destination must be the Virtual IP just created. Moreover, the NAT option must be disabled.

Try to ping the Virtual Servers for VPC from internet, by using the public IP address. The Virtual Servers for VPC should be reachable.

Here are the steps to allow outbound connectivity (from the Virtual Servers for VPC to internet):

Create a Firewall Policy that allows traffic from the internal interface (port 2) to the public interface (port 5). In this case the NAT option must be selected.

Testing the High Availability failover

As the setup on the Fortigate and on the IBM Cloud is complete, we can test a scenario where the primary Fortigate goes down.

The Secondary Fortigate should take over and the SDN Connector, already configured on the Fortigate at deployment time, should allow the reconfiguration of all the routes in the IBM Cloud IBM Cloud VPC.

You should see the IBM Cloud Connector already deployed and configured in your FortiGate, like this

Shutdown the primary FortiGate (you can use the Cloud UI for example) while pinging one of the Virtual Servers for VPCs in the Spoke IBM Cloud VPCs (from any of your Virtual Servers for VPCs simulating the on-premises connectivity).

As the primary FortiGate shutdown, you'll see the ping to fail for few seconds but then working again. The secondary FortiGate took over.

You should prove the IBM Cloud SDN Connector worked by simply verify that all the routes in IBM Cloud have been modified to use, as next hop, the IP address of the interfaces of the secondary FortiGate (10.0.1.20 where the primary FortiGate was 10.0.1.10 for the private traffic).

Routes on the Direct Link route table.

Routes on the Ingress route on the Transit Gateway route table.

You can verify that also the next hop for the public network route table has been dynamically changed from 10.0.4.10 to 10.0.4.20, from the IBM Cloud SDN Connector.