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, it is necessary that the FortiGate-VMs have the correct IP information statically configured in order 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 will be unique and very 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 will be used as a management interface and also the interface from which API calls are made (this will be assigned 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
next
end
port2
Beyond port1 (also the primary VNIC), interface order is arbitrary and can be rearranged. In this example, port2 is assumed to be a public/WAN-facing interface. The following FortiGate configuration does not use the primary IP address for its interface IP address. Instead, it 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 only 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 any extra non-primary private IP addresses are used in the setup, these IP addresses must be referenced explicitly 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
next
end
next
end
port3
This example configures port3 as the internal port, which is used to connect to internal resources on local subnets, peered VCNs, and so on. However, as mentioned earlier, 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
next
end
It is recommended to enable Skip Source/Destination Check for the VNIC.
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
next
end
Additional configuration
For any unconnected subnets or networks, the FortiGate needs a route assigned to know how to get to them. Typically, these will be connected 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 no default route will be configured through DHCP, you must also add this default route. In FortiOS, if no destination is set, the default route of 0.0.0.0/0 is assumed. Therefore, the 2 configuration is the default route.
config router static
edit 2
set gateway 10.0.12.1
set device "port2"
next
edit 3
set dst 10.0.0.0 255.0.0.0
set gateway 10.0.8.1
set device "port3"
next
end
Secondary FortiGate
For the secondary FortiGate, you do not need to configure port2 or port3, as these configurations should sync from the 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 will be used as a management interface and also the interface from which API calls are made (this will be assigned 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.4 255.255.255.0
set allowaccess ping https ssh http fgfm
set description "management"
set mtu-override enable
set mtu 9000
next
end
port2
You must attach the VNIC to the instance with the primary IP address. However, the FortiGate syncs the configuration from the primary unit.
port3
You must attach the VNIC to the instance with the primary IP address. However, the FortiGate syncs the configuration from the primary unit.
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.4 255.255.255.0
set allowaccess ping https ssh fgfm
set description "heartbeat"
next
end