Configuring the OCI HA interfaces

OCI recommends leaving VM NIC interfaces set to DHCP. This is to avoid potential misaligned configurations. However, when configuring an NVA, you may need to ignore this recommendation. When doing so, ensure that the IP addresses correspond with those intended, so that to the extent required, the configurations match.

In the case of HA, the FortiGate-VMs must have the correct IP address information statically configured to provide proper failover between the two devices.

OCI API calls enable the failover mentioned above through the OCI Fabric connector, but only for IP addresses configured as secondary in the OCI VNIC configuration.

Also, OCI API calls, if initiated from within a VCN, must be made by a primary interface with a public address with DNS properly configured. Thus, the network configuration for OCI HA is unique and specific.

You may lose connection to the instance during interface IP address and route configuration. Therefore, performing this configuration via the console is recommended.

Primary FortiGate

port1

The primary VNIC associated with the FortiGate NVA must have a primary IP address with a corresponding public IP address, and so needs to be configured in a public subnet. This is used as a management interface and also the interface from which API calls are made. You assign this in the HA configuration). See this interface's OCI configuration, then the corresponding FortiGate-VM configuration.

config system interface

edit "port1"

set vdom "root"

set ip 10.0.0.3 255.255.255.0

set allowaccess ping https ssh http fgfm

set description "management"

set mtu-override enable

set mtu 9000

end

port2

Beyond port1 (also the primary VNIC), interface order is arbitrary and you can rearrange it. This example assumes port2 to be a public/WAN-facing interface. The following FortiGate configuration does not use the primary IP address for its interface IP address. Instead, the configuration uses the non-primary private IP address, as shown. This is because the primary IP address is not relocatable to the secondary FortiGate in the event of HA failover. In this example, the FortiGate uses a single secondary IP address with an associated public IP address. In the case of a failover, the secondary IP address and associated public IP address are migrated from the active to the passive FortiGate. Therefore, if the setup uses any extra non-primary private IP addresses in the setup, you must explicitly reference these IP addresses in the interface configuration by enabling secondary IP addresses.

config system interface

edit "port2"

set vdom "root"

set ip 10.0.12.3 255.255.255.0

set allowaccess ping https ssh fgfm

set description "untrust"

set secondary-IP enable

set mtu-override enable

set mtu 9000

config secondaryip

edit 1

set ip 10.0.12.5 255.255.255.0

set allowaccess ping https ssh fgfm

end

port3

This example configures port3 as the internal port, which the configuration uses to connect to internal resources on local subnets, peered VCNs, and so on. However, as aforementioned, FortiGate does not use the primary IP address. You must still attach the VNIC to the instance with the primary IP address. However, the configuration is synced from the primary FortiGate.

config system interface

edit "port3"

set vdom "root"

set ip 10.0.8.10 255.255.255.0

set allowaccess ping https ssh fgfm

set description "trusted"

set mtu-override enable

set mtu 9000

end

Enabling Skip Source/Destination Check for the VNIC is recommended.

port4

This example uses port4 as the HA interface for heartbeat and configuration synchronization. As such, it only needs a single private IP address.

config system interface

edit "port4"

set vdom "root"

set ip 10.0.10.3 255.255.255.0

set allowaccess ping https ssh fgfm

set description "heartbeat"

set mtu-override enable

set mtu 9000

end

Additional configuration

For any unconnected subnets or networks, the FortiGate needs a route assigned to know how to get to them. Typically, you connect these via the internal designated interface. In this case, this is port3. Therefore, a route with a next hop or gateway of the first IP address of the subnet to which port3 belongs is necessary. This can be a specific host route or summary route of some sort.

See the following, where a summary route is configured for 10.0.0.0/16. If this route is not added, the FortiGate communicates with any unconnected routes through the default (0.0.0.0/0) route, which typically should be out the WAN interface (port2 in this example). Since all interfaces are being configured statically and you are not configuring a default route through DHCP, you must also add this default route. If you do not set a destination, FortiOS assumes the default route of 0.0.0.0/0. Therefore, the 2 configuration is the default route.

config router static

edit 2

set gateway 10.0.12.1

set device "port2"

edit 3

set dst 10.0.0.0 255.0.0.0

set gateway 10.0.8.1

set device "port3"

end