FortiGate interfaces, management, console and HA ports

A real-life situation

Corbridge Freight, a fictional company, is replacing an old firewall at its head office with two FortiGates in an HA pair. The installer racks both units, connects the Internet to the ports labelled WAN, plugs the HA ports into the core switch "because there was a free VLAN", and enables HTTPS on the WAN interface so a contractor can manage the firewalls from home. Within a month, the logs show thousands of login attempts from the Internet, and a switch reboot causes both FortiGates to become primary at once.

Every one of these problems was decided at the port-planning stage, before any policy was written. This lesson covers what each port is for and how to plan them.

What the ports on a FortiGate are

Front panels differ a lot between models, so the first step with any FortiGate is to read its QuickStart guide or hardware guide. These are the port types you will meet:

Names, numbers and defaults vary by model and sometimes by firmware release. Labels on the case show the intended role; FortiOS treats most of them as ordinary interfaces you can configure for any role.

FortiGate VM ports

A FortiGate VM has no physical ports. Each virtual NIC that the hypervisor attaches appears as port1, port2 and so on, in the order the hypervisor presents them, and port1 is normally used for first access. There is no console port: you use the hypervisor's console window instead. If interfaces come up in an unexpected order after adding NICs, compare the MAC addresses in FortiOS with the ones in the hypervisor.

Logical interfaces built on ports

A physical port is the starting point. FortiOS builds logical interfaces on top of ports, and policies can use either:

• VLAN: one 802.1Q VLAN on a parent port; many networks on one cable.
• Aggregate: several ports bundled with LACP; redundant: several ports with one active.
• Hardware switch / software switch: several ports acting as one switched network with one IP address.
• Loopback and tunnel interfaces: virtual interfaces that need no port of their own.

Learn more: FortiGate Interfaces, VLANs, Aggregates and Zones

Management: in-band or out-of-band

In-band management means administrators reach the FortiGate over the same networks that carry user traffic, for example HTTPS to the LAN interface. Out-of-band (OOB) management uses a separate network, often a dedicated switch and VLAN, that carries only management traffic.

The console port is the last line of OOB access. It works with no IP configuration at all, which is why a console server (or at least a known console cable) for every important FortiGate saves long outages.

The two OOB switches form one management network (10.0.9.0/24), joined to each other and to the administrators' VPN or jump host outside the picture. No user traffic crosses it.

Administrative access per interface

Every interface has an allowaccess list: the management protocols the FortiGate itself answers on that interface. Anything not in the list is ignored there. It controls traffic to the FortiGate, not traffic through it.

Trusted hosts

allowaccess decides where the FortiGate listens. Trusted hosts decide who may log in: each administrator account can list up to ten source subnets, and logins from anywhere else are refused.

For extra control, the management ports can be changed (admin-sport and admin-ssh-port under config system global), and local-in policies can filter traffic to the FortiGate itself by source, interface and service.

Learn more: Admin Accounts, Backups and Firmware

Management in an HA cluster

In an FGCP cluster, configuration is synchronised, so both units would normally share the same interface addresses, and only the primary answers them. To reach each unit on its own, for monitoring, SNMP or firmware checks, you can reserve a management interface per unit. Its address is not synchronised, so each unit keeps its own.

HA heartbeat links

Cluster members exchange heartbeats several times a second, and use the same links to synchronise configuration and, if enabled, sessions. If every heartbeat link fails while both units are still running, each unit believes the other is gone and both become primary: a split brain, with two devices answering for the same addresses.

• Use two heartbeat links, so one failed cable or port doesn't break the cluster.
• Connect them directly, unit to unit, where the units are close. If they must cross switches, use dedicated switches or isolated VLANs that carry nothing else.
• Keep data off them. Heartbeat ports should not also carry user traffic; a busy data link can delay heartbeats and trigger false failovers.
• Match ports on both units. FGCP clusters need identical models, so ha1 on one unit connects to ha1 on the other.

Learn more: High Availability with FGCP

The console port

• Connector: RJ-45 on most models, with an RJ-45 to DB-9 or USB serial cable; some newer models also have a USB console port.
• Settings: by default on most models 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
• Why it matters: it works when no interface has an address, when management access has been removed by mistake, and during firmware upgrades, where it shows boot messages that no network session can.

Identifying ports from the CLI

Before cabling, confirm that the port you are about to use is the one you think it is, that it has link, and at what speed.

FGT1 # get system interface physical
== [onboard]
        ==[mgmt]
                mode: static
                ip: 10.0.9.1 255.255.255.0
                status: up
                speed: 1000Mbps (Duplex: full)
        ==[port1]
                mode: static
                ip: 203.0.113.2 255.255.255.252
                status: up
                speed: 1000Mbps (Duplex: full)
        ==[x1]
                mode: static
                ip: 0.0.0.0 0.0.0.0
                status: down
                speed: n/a
...

FGT1 # get hardware nic port1
Name:            port1
...
Link:            up
Speed:           1000
Duplex:          full
...
Current_HWaddr   00:09:0f:xx:xx:xx
Permanent_HWaddr 00:09:0f:xx:xx:xx
...

Speed and duplex

Ports auto-negotiate by default. If the device at the other end has a fixed speed, set the same fixed speed and duplex on both sides; a mismatch (one side auto, the other fixed) commonly ends in a half-duplex link with errors and poor performance.

Planning a port map

Write the port map before installation, and keep it with the network documentation. Here is the plan for Corbridge Freight's HA pair, using a hypothetical mid-range model with ten copper ports, two SFP+ cages, two HA ports and one MGMT port:

A good port map also records the cable or patch panel ID, the switch port at the other end, the transceiver type, and spare ports reserved for growth.

Verification

• get system interface physical: every planned port is up at the expected speed; unused ports are down.
• get system ha status: both units are in the cluster and heartbeats are seen on both links.
• From the admin PC on the OOB network, reach each unit by its own management address with HTTPS and SSH.
• From the Internet side, confirm the WAN address doesn't answer HTTPS or SSH.

Common mistakes and how to fix them

Management exposed on the WAN interface

HTTPS or SSH is in the WAN interface's allowaccess list, often added once "for a quick remote fix". The logs show constant failed logins from Internet addresses, and any future vulnerability in the management interface is reachable from anywhere.

HA heartbeat through a switch shared with data

The heartbeat ports are connected through the core switch. A switch reboot, a spanning-tree change or a broadcast storm interrupts heartbeats, and both units become primary.

Splitting the hardware switch and losing the LAN

On a desktop model, an administrator removes one port from the built-in LAN hardware switch to use it as a DMZ. The change is refused, or it succeeds and the administrator's own connection drops because they were plugged into that port.

Wrong transceiver

A new SFP+ port shows status: down although the cable is plugged in. The optic is multimode short-range (SR) while the fibre run is single-mode, or the module is a speed the cage doesn't support, or it isn't a supported module for this model.

Enterprise design guidance

• Separate the three kinds of connection: data ports, heartbeat ports and management ports, each with its own cabling.
• Build an OOB network for firewalls, switches and console servers in data centres and large sites, reachable through its own VPN or jump host.
• Plan for offload: on models with several network processors, ports on the same NP can offload sessions between each other more efficiently. The hardware acceleration guide lists the mapping.
• Leave spare ports on both units of a cluster, in matching positions, for later growth.
• Standardise: use the same port roles across every site with the same model, so configurations and runbooks stay alike.

Best practices

• Allow management protocols only on the management interface or trusted internal interfaces.
• Set trusted hosts on every administrator account.
• Use two direct heartbeat links that carry no data traffic.
• Keep a tested console path to every important FortiGate.
• Document a port map before installation and update it with every change.

Key takeaways

Check yourself

Next in Fortinet Fundamentals: what happens behind the ports, in Security processors and hardware acceleration.