FortiGate in the public cloud

Harbourline Retail moves its web shop into AWS

Harbourline Retail, a fictional company, runs its offices behind FGT1 from the course lab. Its web shop is moving from WEB1 in the DMZ to SHOP1, a server in an AWS VPC. The security team wants the same protection in the cloud that the DMZ had: inbound HTTPS only, IPS on that traffic, outbound access only for updates, and logs in the same format as FGT1's. A FortiGate-VM, called FGT-AWS here, will sit in front of SHOP1.

The course lab is on premises, so this lesson adds its own addresses: a VPC 10.100.0.0/16 with a public subnet 10.100.1.0/24 and a private subnet 10.100.2.0/24. The Elastic IP is shown as 203.0.113.50, a documentation address standing in for the public address AWS would allocate.

What the cloud provider secures, and what stays with you

AWS and Azure both publish a shared responsibility model. The provider secures the data centres, hardware, hypervisor and its own network. You secure what you build on top: which ports are open, which routes exist, what the operating systems run, who holds API keys, and what traffic is allowed between your workloads. A FortiGate-VM is part of your side of that line. Its licence, firmware, configuration and logs are yours to manage, and so is the cloud bill: Fortinet's AWS guide reminds you that compute, storage, snapshots and data transfer are charged to you whichever licence you use.

The problems that bring firewalls into cloud designs are mostly of the customer's own making:

• Misconfiguration. One security group rule allowing 0.0.0.0/0 exposes a database to the whole internet in seconds.
• Stolen credentials. Leaked access keys or admin passwords let an attacker change the network itself, not just attack it.
• East-west movement. Inside a VPC, instances in different subnets can reach each other through the local route unless something says otherwise.
• Limited inspection. Native controls filter on addresses and ports. They don't see the exploit inside an allowed HTTPS session.
• Constant change. Instances appear and disappear with new addresses, so static address objects go stale quickly.

The FortiGate-VM answers the inspection and consistency problems: the same FortiOS policies, IPS and logging as on premises. It doesn't fix weak credentials or open security groups; those stay on your checklist.

How the VPC hands traffic to FGT-AWS

In a VPC there is no cable to move. A subnet's route table decides where its traffic goes, and Fortinet's single-VM design uses two of them:

SHOP1 still sends its packets to the VPC router at 10.100.2.1 (AWS reserves each subnet's .1 address for it). The private route table then forwards anything non-local to FGT-AWS's private interface. That is the cloud version of setting a server's default gateway to the firewall.

Two AWS behaviours shape the FortiGate configuration. First, the internet gateway does 1:1 NAT between the Elastic IP and port1's private address, so 203.0.113.50 doesn't appear on any FortiOS interface; inbound packets arrive addressed to 10.100.1.10. Second, AWS drops packets that arrive at an interface but aren't addressed to it, unless that interface's source/destination check is disabled. A firewall forwards traffic for other hosts, so the check must be off on its interfaces.

Building the deployment in the AWS console

These are the steps of the "Single FortiGate-VM deployment" section of the FortiGate Public Cloud 7.6 AWS guide, with this lesson's values. Console menus move between AWS releases, so look for the names rather than the positions.

The marketplace offers a predefined security group for the instance with SSH, HTTP, HTTPS, TCP 541 for an external FortiManager and a few others open. Fortinet's own guidance is to tighten it: allow only what you need, starting with HTTPS for management. For Harbourline that means TCP 443 from anywhere (the shop) and the admin port from FGT1's public address, 203.0.113.2, only.

FortiOS settings on FGT-AWS

Inside the VM, the configuration is ordinary FortiOS. One conflict needs solving first: the shop and the admin GUI both want TCP 443 on 10.100.1.10. Moving administrative HTTPS to another port frees 443 for the VIP.

In the GUI the same objects live under Policy & Objects › Virtual IPs and Policy & Objects › Firewall Policy; the route is under Network › Static Routes. The IPS sensor sees the HTTPS handshake but not the requests inside it; to inspect those, apply an SSL inspection profile that uses SHOP1's own certificate.

Learn more: Virtual IPs: Publishing Servers · SSL/TLS Inspection

Checking that traffic really passes through FGT-AWS

Cloud routing mistakes are silent: traffic either takes another path or vanishes before it reaches the VM. Check from the FortiGate outwards.

FGT-AWS # get router info routing-table all
Routing table for VRF=0
S*      0.0.0.0/0 [10/0] via 10.100.1.1, port1, [1/0]
C       10.100.1.0/24 is directly connected, port1
C       10.100.2.0/24 is directly connected, port2

FGT-AWS # diagnose sniffer packet any 'host 10.100.2.20 and port 443' 4
port1 in 198.51.100.77.60311 -> 10.100.1.10.443: syn 2203441
port2 out 198.51.100.77.60311 -> 10.100.2.20.443: syn 2203441
port2 in 10.100.2.20.443 -> 198.51.100.77.60311: syn 3381220 ack 2203442
port1 out 10.100.1.10.443 -> 198.51.100.77.60311: syn 3381220 ack 2203442

Also run get system status once after deployment: the Version line names the VM platform image and the build, and the licence status confirms that a BYOL licence was accepted. On Azure, Fortinet's guide shows the platform as FortiGate-VM64-AZURE for BYOL and FortiGate-VM64-AZUREONDEMAND for PAYG, which is a quick way to tell which model you are looking at.

When FGT-AWS sees nothing, or too much

SHOP1 can't reach the internet, and the sniffer on port2 is empty

The private route table points 0.0.0.0/0 at eth1's interface, and the policy is correct, yet diagnose sniffer packet port2 'host 10.100.2.20' 4 shows nothing when SHOP1 tries to update.

Visitors reach the FortiGate login page instead of the shop

The VIP was created with extip 203.0.113.50, the Elastic IP, and the admin port is still 443.

An on-demand FGT-AWS shuts itself down a few minutes after boot

The instance launches, then powers off. The private subnet works in testing, but the VM doesn't stay up.

Inbound HTTPS shows nothing at all on port1

The VIP and policy look right, but the sniffer on port1 stays empty while a visitor tries to connect.

BYOL or PAYG for the FortiGate-VM

The models are not interchangeable on one instance, so decide before you deploy. PAYG suits short projects and uncertain sizing; BYOL suits long-lived firewalls and the same ordering process you use for other platforms. Licences are sized by vCPU, so the instance type you choose and the licence you buy must match.

The same design in Azure

The idea carries over to Azure with different names. The Azure guide's single-VM example uses three subnets: external (port1), internal (port2, a transit network) and a protected subnet for the workloads.

Larger designs build on this one: an active-passive pair (on failover, the new primary uses AWS or Azure API calls to take over addresses and routes), or several FortiGate-VMs behind a cloud load balancer with autoscaling. Fortinet's SDN connectors let policies match cloud metadata such as instance tags instead of fixed addresses, which deals with the constant-change problem above.

Learn more: High Availability (FGCP)

FortiGate CNF: the firewall you don't operate

A FortiGate-VM is yours to size, patch, license, cluster and scale. FortiGate CNF (Cloud-Native Firewall) removes that work. It is a software-as-a-service firewall: Fortinet runs the firewall infrastructure in AWS or Azure, scales it on throughput, CPU and memory, and you manage policy from the FortiGate CNF console. One CNF instance serves one region and can protect many VPCs (or VNets), availability zones and accounts with a shared policy.

The onboarding wizard on first login walks through three steps:

1. Add cloud accounts. FortiGate CNF needs permissions in each account it protects, granted by running the CloudFormation template (AWS) or ARM template (Azure) it provides. The billing account can be a different one.
2. Create a policy set. An ordered group of policies, applied to an instance as a whole. A built-in allow_all set exists for testing routing only; it gives no protection.
3. Create the CNF instance and its endpoints. In AWS, each endpoint is a Gateway Load Balancer endpoint placed in a subnet you created and tagged (fortigatecnf_subnet_type = endpoint). Your route tables then send traffic to that endpoint, much as the private route table above sends it to FGT-AWS.

In the CNF console, security profiles offer DNS filtering, known bad IP blocking and a choice of preset IPS profiles. Instances created in FortiManager mode are managed from FortiManager instead, where the wider set of FortiOS profiles is available. Logs can go to an S3 bucket or AWS Security Lake, and externally to syslog or FortiAnalyzer.

For Harbourline the choice is clear for now: one shop server, a VPN back to FGT1 planned, and a team that already runs FortiOS. FGT-AWS fits. If the company grows to dozens of VPCs across several accounts, CNF becomes the cheaper option to operate.

Test yourself on FortiGate in the public cloud