WHITE PAPER

FortiGate Secure SD-WAN

on Google Cloud
Reference Architecture
Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

The shared responsibility model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Hybrid cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Key Google Cloud Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Regions and zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Virtual Private Cloud (VPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

VPC routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

VPC peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Firewall rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Cloud VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Cloud router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

FortiGate Next-generation Firewall VM on Google Cloud . . . . . . . . . . 9

FortiManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

FortiGuard security services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Instance type support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

FortiGate VM deployment on Google Cloud . . . . . . . . . . . . . . . . . . . 11

2
 Deploying a single FortiGate VM on Google Cloud . . . . . . . . . . . . . 11

North-south traffic inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

East-west traffic inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

FortiGate Secure SD-WAN overview . . . . . . . . . . . . . . . . . . . . . . . . . 13

FortiGate integrated NGFW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

WAN path remediation for business-critical applications . . . . . . . . 14

Dynamic address-based SD-WAN rules . . . . . . . . . . . . . . . . . . . . . . 15

Link aggregation to maximize bandwidth. . . . . . . . . . . . . . . . . . . . . 15

Design Pattern/Deployment Scenarios Using FortiGate for

Google Cloud Multi-VPC Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . 15

VPN from on-premises FortiGate to cloud router in hub VPC

through the internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

VPN from on-premises FortiGate to FortiGate cluster in

hub VPC(s). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

VPN from on-premises FortiGate to FortiGate cluster in hub

VPC(s) through interconnect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Connect GKE on-premises and GKE using FortiGate Secure

SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Executive Summary
The public cloud, often referred to as the cloud, is a popular model of cloud computing. Cloud
service providers leverage the internet and make resources such as infrastructure, storage, and
servers available for businesses. Third-party providers own and operate the shared physical
hardware and offer it to companies based on their needs. This multitenant environment makes it
easier to spread the infrastructure costs across a number of users. Companies around the globe are
adopting the cloud to take advantage of core characteristics:

Cost effectiveness. By using cloud infrastructure, customers do not need to spend large amounts of
money on purchasing and maintaining equipment. This drastically reduces capital expenditure (CapEx)
costs, saving companies the resources and time to invest in hardware, facilities, and utilities, or to
build out a large data center to grow their business.

Scalability. Cloud-based solutions are ideal for businesses with growing and fluctuating bandwidth demands. If business
demands increase, customers can easily increase their cloud capacity without investing in more physical infrastructure.
This level of agility provides businesses a key advantage over competitors.

Disaster recovery. Data loss is a major concern for all organizations. Storing customer data in the cloud guarantees that
data is always available, even if equipment such as laptops or PCs is damaged. Cloud-based services provide quick data
recovery for emergency scenarios—from natural disasters to power outages.

Increased agility. Today, businesses need to be more dynamic to be productive. They need to continuously evolve
and improve their processes, tools, technologies, and policies. Being agile enables businesses to make faster decisions
and prioritize the work and ensure customer satisfaction. With the cloud, businesses experience better delivery, better
collaboration, and faster rollouts of new business initiatives.

The shared responsibility model

While cloud providers manage the security of the cloud, security in the cloud is the responsibility of the customer.
Customers retain control of what security they choose to implement to protect their content and applications.

Cloud providers operate, manage, and control the components from the host operating system and virtualization layer down
to the physical security of the facilities in which the service operates. However, customers retain ownership and control of
their data and are responsible for configuring and deploying security baselines within their environments.

Figure 1: The shared responsibility model.

4
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Hybrid cloud
Although public cloud platforms have been adopted by a large number of customers, many organizations prefer to
maintain a sizable portion of their deployments on-premises. Additionally, an increasing number of customers are
adopting a multi-cloud strategy where their applications and data are deployed across multiple public clouds as well as
on-premises. This trend has made secure connectivity to the cloud, as well as between different cloud platforms, a top
concern for many organizations.

Google Cloud is a popular cloud provider that businesses use in their hybrid cloud environment. With the Fortinet FortiGate
next-generation firewall (NGFW) appliance deployed on-premises and its virtual machine (VM) form factor deployed on
Google Cloud—along with powerful software-defined wide-area networking (SD-WAN) capabilities—customer on-premises
and cloud deployments can connect in an efficient and secure manner. Additionally, FortiGate provides the best-of-breed
next-generation security to protect customer workloads against sophisticated cyberattacks.

Key Google Cloud Concepts

Since the main objective of this document is to explain architecture and deployment scenarios of FortiGate Secure SD-
WAN on Google Cloud, a good knowledge of the Google Cloud concepts and key Google Cloud services is a prerequisite to
understanding design topics discussed in this guide.

Regions and zones

A zone is a deployment area for Google Cloud resources. It is the finest-grained Google Cloud infrastructure construct that
users can specify when deploying Google Cloud resources. A group of zones form what is known as a region, which can
also be specified when resources are created. The zones in each region are connected via low-latency links to enable fast
connectivity between resources inside a region regardless of the zones that they are associated with.

All Google Compute Engine resources are either global, regional, or zonal. For example, images are a global resource, but
persistent disks are either regional or zonal resources. The scope of the resource determines how accessible the resource is
to other resources. For example, global resources are accessible by resources in any region or zone, so VM instances from
different zones can use the same global image. Regional resources are accessible only to resources within the same region.
For example, a regional static external Internet Protocol (IP) address is accessible only by resources within the same region.

Each zone is a single failure domain within a region. Therefore, in order to take advantage of the fault tolerance and
isolation offered by the zones, it is necessary to distribute applications as well as security services that are deployed to
protect them across multiple availability zones. Additionally, many Google Cloud customers deploy their applications in
more than one region to protect against the loss of an entire region due to natural disasters.

Google Cloud Project

Network: Default

Region 1 Region 2

Zone a Zone b Zone a Zone b

Low-latency link Low-latency link

Zone c Zone c

Figure 2: Google Cloud regions and zones.

5
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Organization
The Google Cloud resource hierarchy includes an optional organization resource Customers should consider
and folders. This allows companies to map their organization onto Google Cloud their overall network map before
and provide logical attach points for access management policies (cloud IAM) and creating VPCs and defining
organization policies. The organization resource is the root node in the Google Cloud classless inter-domain routing
resource hierarchy, and provides centralized visibility and control over every resource (CIDR) to them just as when
that belongs to an organization. assigning CIDRs in physical
data centers. This will help
avoid issues such as IP address
Folders
overlapping after instances are
Folders are a group of projects and subfolders that provide logical separation within deployed in Google Cloud.
an organization. Folders can only be used when an organization resource is used.
Hierarchically, folders can be seen as suborganizations. For example, the top-level
folders can be mapped to the different departments within an organization. Since folders can contain projects and other folders,
each folder could then include other subfolders, to represent different teams. Within each team folder, users can include folders
for different applications.

Project
A project consists of a set of users, a set of application programming interfaces (APIs), and billing, authentication, and monitoring
settings for those APIs. Customers can create multiple projects and use them to organize their resources. By default, resources
within a project are accessible to other resources in that project, as long as their API is enabled, and are inaccessible to anything
outside of the project. For example, if a user creates a cloud SQL database and a cloud storage bucket, a VM inside the project
can access both resources by default, but a VM outside of the project could not. This goes a long way toward setting up safe
permission structures.

Virtual Private Cloud (VPC)

Google Virtual Private Cloud (VPC) is a private isolated virtual network partition that gives users managed networking
functionality for their Google Cloud resources. This virtual network closely resembles a traditional network that customers would
operate in their own data center, with the benefits of using the scalable Google Cloud infrastructure.

Contrary to other cloud providers such as Amazon Web Services, Google VPC is a global construct. A single Google VPC can
span multiple regions without needing to communicate across the public internet. It provides the same private gateways for the
on-premises hardware, but also gives users global scope between regions, sharable configuration between their projects, and
near real-time logging to monitor their applications. It also comes with a full suite of support services such as Shared VPC, Cloud
Router, firewall support, VPC peering, and a managed virtual private network (VPN) service. Google VPC networking allows VMs
to communicate across regions without requiring extra overhead from VPNs. This means that Google handles traffic under the
hood by dynamically advertising routes across the VPC, which is abstracted from the users.

By default, every instance in a VPC has a route to all other instances within that VPC. Additionally, all instances have a route to
the default internet gateway that comes installed in the VPC route table when a VPC is created. However, in order to establish
an internet connection from the private instances, a network address translation (NAT) gateway, or a cloud NAT, needs to be
configured. Public instances that have external IP addresses can directly reach outside resources, and customers who need
connectivity between their VPC and on-premises location can create a VPN gateway within their VPC. IP security (IPsec) VPN
connections can then be established between the VPN gateway and the on-premises customer gateway.

Subnets
Each VPC network consists of one or more useful IP range partitions called subnetworks or subnets. Each subnet is associated
with a region. By themselves, VPC networks do not have any IP address ranges associated with them because IP addresses are
defined with subnets.

6
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Google Cloud offers two types of VPC networks, determined by their subnet creation mode:

Auto-mode network. When an auto-mode network is created, one subnet from each region is automatically created within
it. These automatically created subnets use a set of predefined IP ranges that fit within the 10.128.0.0/9 CIDR block. As new
Google Cloud regions become available, new subnets in those regions are automatically added to auto-mode networks
using an IP range from that block. In addition to the automatically created subnets, users can manually add more subnets
to auto-mode networks in the regions they choose using IP ranges outside of 10.128.0.0/9.

Custom-mode network. No subnets are automatically created in this mode. This type of network provides users with
complete control over its subnets and IP ranges. Users decide which subnets to create in regions they choose and specify
IP ranges.

An auto-mode network can be converted to a custom-mode network. However, this is a one-way conversion. No custom-
mode network can be converted back to an auto-mode network.

When a subnet is created, a primary IP address range must be defined. Users can define secondary IP address ranges,
but they are only used as alias IP addresses. There are four reserved IP addresses in a subnet’s primary IP address range
that cannot be assigned to an instance. For example, if a subnet’s primary CIDR is 10.1.7.0/24, the following four addresses
are reserved:
nn10.1.7.0: Network address
nn10.1.7.1: Default gateway
nn10.1.7.254: Reserved by Google Cloud for potential future use
nn10.1.7.255: Broadcast address

VPC routing
The VPC network uses a distributed virtual routing mechanism. The routing table for a VPC network is defined at the VPC
network level and routes are considered a network resource, which means they cannot be shared between projects or
networks. VPC networks can include two types of routes:

System-generated routes. These routes are created when a VPC and its subnets are created:
nnDefault route defines the path out of the VPC network, including the path to the internet. Additionally, it provides the
path for Google private access, such as APIs and services. Note that in addition to the default route, instances need to
have either an external IP address or use a cloud NAT/NAT instance in order to have internet connectivity.
nnSubnet route means that each subnet has at least one designated route whose destination matches the primary IP
range of the subnet. If the subnet has secondary IP ranges, Google Cloud creates a subnet route with a corresponding
destination for each secondary range.
Custom routes. Custom routes are either statically created by users or dynamically populated via cloud routers:
nnStatic routes are often created manually to steer traffic to a static route next hop such as an instance.
nnDynamic routes always have the next hop of the Border Gateway Protocol (BGP) peer IP address and are managed by
cloud routers.
Custom routes cannot have a destination IP address range that matches or is more specific than any subnet route in the VPC.

Each instance has a set of applicable routes, which are a subset of all routes in the VPC network. Applicable routes are
the possible egress paths that a packet can take when sent from the instance. System-generated routes apply to all
instances within the VPC network but custom routes can be applied to all instances or a subset of instances based on the
network tag. For example, in Figure 3 there are two default routes in the VPC route table: one system-generated default
route and another default route that has a network tag, meaning it will only apply to the instances that have the same tag.
The private instance in this example has the same network tag as this route. However, the system-generated default route
also applies to this private instance. This is where the route priority comes into play. Since the custom default route has a
higher priority (800), packets leaving the private instance will be directed to the NAT gateway instance shown in Figure 3.

7
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Internet

Google Cloud Project

VPC Network: hub VPC Routing

Us-central-1 Destination IP range Priority Instance tags Next hop

192.168.1.0./24 1000 None Virtual network hub

subnet-a-west:192.168.1.0/24
192.168.2.0/24 1000 None Virtual network hub

0.0.0.0/0 1000 None Default Internet gateway

Private instance NAT gateway
0.0.0.0/0 800 no-ext Instance NAT gateway

us-east-1

192.168.1.2 192.168.1.3 subnet-a-east: 192.168.2.0/24

Instance-tag: no-ext
IP forwarding enabled
Resources

Figure 3: Google Cloud VPC networking.

NAT gateways and third-party network virtual appliances that act as a gateway need to have IP forwarding enabled on their
network interfaces.

VPC peering
VPC network peering enables users to peer VPC networks so that workloads in different VPC networks can communicate in
private RFC 1918 space. Traffic stays within the Google network and does not traverse the public internet. It has advantages
over other connectivity options such as external IP and VPN due to low latency as well as cost benefits. Also, users do
not need to have their services exposed to the public internet, limiting risk. Each side of a peering association is set up
independently. However, peering will be active only when the configuration from both sides matches. Either side can choose
to delete the peering association at any time.

By default, subnet routes are always exchanged between peered networks. Users can also exchange custom routes, which
include static and dynamic routes, if network administrators in both networks have the appropriate peering configurations.

When users import custom routes, the VPC network can receive custom routes from the peer network only if that network is
exporting them. Similarly, if users export custom routes, the peer network can receive custom routes only if that network is
importing them. When importing or exporting custom routes, networks only exchange custom routes with direct peers. For
example, if a VPC network is peered with multiple networks, routes that this network imports from one peered network aren’t
exported to the other peered networks.

There are some limitations with VPC peering services. One of the key restrictions is that VPCs with overlapping CIDR cannot
establish a peering relationship. Also, transitive routing with VPC is not supported. For example, if VPC A is peered with VPC B
and VPC B is peered with VPC C, VPC A will not have a route to VPC C.

Firewall rules
Firewall rules allow users to isolate internal networks and instances from unwanted access. They allow monitoring of inbound
and outbound activity coming from customer networks and block items that are considered dangerous based on a set of
security rules. Every VPC network functions as a distributed firewall. While firewall rules are defined at the network level,
connections are allowed or denied on a per-instance basis.

Every VPC network has two implicit rules that cannot be removed but can be overridden by higher-priority rules.

8
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Allow egress rule. An egress rule whose action is set as allow, destination is 0.0.0.0/0, and priority is the lowest possible
(65535) allows any instance to send traffic to any destination, except for traffic blocked by Google Cloud.

Deny ingress rule. An ingress rule whose action is set to deny, source is 0.0.0.0/0, and priority is the lowest possible
(65535) protects all instances by blocking incoming traffic to them.

Google Cloud always allows communication between a VM instance and its corresponding metadata server at
169.254.169.254 regardless of any firewall rules that users configure.

Firewall rules are composed of the following configuration components:

nnPriority
is a numerical value used to determine if the rule will be applied. Only the highest-priority rule whose other
components match traffic is applied.
nnDirectionof traffic is determined by ingress and egress rules. Ingress rules apply to incoming connections from specified
sources to Google Cloud targets, and egress rules apply to traffic going to specified destinations from targets.
nnAn action with either allow or deny options will determine if the rule permits or blocks traffic.
nnA target defines the instances to which the rule will apply.
nnA source applies to ingress rules and a destination applies to egress rules.
nnA protocol (such as TCP, UDP, or ICMP) and port.

Cloud VPN
Cloud VPN securely connects a customer’s peer network to their Google Cloud VPC through an IPsec connection. Google
Cloud currently supports two types of cloud VPN service: high availability (HA) VPN and classic VPN.

HA VPN is an HA cloud-based VPN solution that allows customers to securely connect their on-premises network to
their Google Cloud VPC network through an IPsec VPN connection in a single region. HA VPN provides a service-level
agreement (SLA) of 99.99% service availability. When a user creates an HA VPN gateway, Google Cloud automatically
chooses two public IP addresses, one for each of its fixed number of two interfaces. Each IP address is automatically
chosen from a unique address pool to support HA. Cloud VPNs support both static and dynamic routing modes. However,
in order to establish BGP sessions with on-premises VPN gateways, a Google Cloud Cloud Router is required.

Cloud router
A cloud router is a managed Google Cloud service that is used to dynamically exchange routes between Google Cloud
networks and the customer’s on-premises network. Cloud routers peer with the customer’s on-premises VPN gateway or
router. The routers exchange topology information through BGP. Topology changes automatically propagate between the VPC
network and on-premises network. No configuration of static routes is required. Networks automatically and rapidly discover
topology changes through BGP, and are seamlessly implemented without disrupting traffic. Exchanging routes through BGP is
dynamic routing, which frees customers from maintaining static routes. Also, if a link fails, dynamic routing can automatically
reroute traffic. Once a cloud router is created, customers can configure a BGP session between their on-premises network
gateway and the cloud router to enable dynamic routing.

FortiGate Next-generation Firewall VM on Google Cloud

FortiGate NGFW technology delivers complete content and network security. The solution combines stateful inspection
with a comprehensive suite of security features including antivirus, intrusion prevention system (IPS), web filtering,
application control, web application firewall, and more. FortiGate VM is available for deployment on Google Cloud and helps
customers secure their cloud architecture.

In addition, FortiGate VM provides IPsec VPN, secure sockets layer (SSL) VPN, support for dynamic routing protocols such as
BGP, and integration with authentication servers including LDAP and RADIUS. With this extensive feature set, FortiGate VM can be
deployed in public cloud environments such as Google Cloud to identify and mitigate the latest and most complex cyber threats.

FortiGate VM on Google Cloud can:

nnProtect against known exploits and malware using continuous threat intelligence provided by FortiGuard Labs security services
nnAchieve visibility into all types of traffic across the cloud with SSL inspection

9
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

nnIdentify thousands of applications including cloud applications for deep inspection into network traffic
nnProtect against unknown attacks using dynamic analysis, providing automated mitigation to stop targeted attacks

FortiManager
FortiManager virtual security management appliances for Google Cloud offer the same powerful network security management
features as FortiManager hardware-based appliances, with the addition of a stackable license model that enables easy growth
with your network environment. Fortinet virtual appliances allow customers to deploy a mix of hardware and virtual appliances
that operate together and are managed from a common centralized FortiManager platform.

FortiGuard security services

FortiGuard Labs offers real-time intelligence on the threat landscape, delivering comprehensive security updates across
the full range of Fortinet solutions. Comprised of security threat researchers, engineers, and forensic specialists, the
FortiGuard Labs team collaborates with the world’s leading threat monitoring organizations and other network and security
vendors, as well as law enforcement agencies, to study threats and develop solutions that keep organizations secure.

Licensing
With a multitude of deployment methods supported across various private and public cloud deployments, FortiGate VM for
Google Cloud supports both on-demand pay-as-you-go (PAYG) licensing and bring-your-own-license (BYOL) models.

PAYG is a highly flexible option for both initial deployments and that allows them to grow as needed. PAYG licenses offer value
and cost savings for auto-scaling environments where the VM instances are scaled. With a wide selection of supported instance
types, there is a solution for every use case. This license comes with FortiOS as part of the unified threat management (UTM)
bundle. To purchase PAYG, customers simply subscribe to the product on the Google Cloud Marketplace.

BYOL is annual perpetual licensing available for purchase from resellers or distributors. BYOL licensing provides the same
ordering practice across all private and public clouds, regardless of platform. Customers must activate a license for the first time
accessing the instance before using various features. BYOL is ideal for migration use cases, where an existing private cloud
deployment is migrated to a public cloud deployment. When using an existing license, the only additional cost is the price for the
Google Cloud instances.

Instance type support

FortiGate VM supports the following instance types on Google Cloud:

FortiGate for Google Cloud can be deployed as VM instances. Supported machine types may change without notice.
Currently, FortiGate supports standard machine types, high-memory machine types, and high-CPU machine types with
minimum 1 vCPU and 3.75 GB of RAM, and maximum 96 vCPUs and 624 GB of RAM in the predefined machine type lineup.
Users can customize the combination of vCPU and RAM sizes within this range. Learn more about predefined machine types.

Each FortiGate VM instance requires four network interfaces when it is running in active-passive HA mode. This is explained
later in this guide. The following table shows the BYOL models conventionally available to order:

Model Name vCPU Minimum vCPU Maximum

FG-VM01/01v/01s 1 1
FG-VM02/02v/02s 1 2
FG-VM04/04v/04s 1 4
FG-VM08/08v/08s 1 8
FG-VM16/16v/16s 1 16
FG-VM32/32v/32s 1 32
FG-VMUL/ULv/ULs 1 Unlimited

Table 1: FortiGate VM models (BYOL).

10
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

The V series does not support VDOM by default. To run VDOM on VM models, customers must purchase additional VDOM
licenses.

FortiGate VM deployment on Google Cloud

The most basic deployment consists of one FortiGate VM with two network interfaces—one in external or public VPC and
another in internal VPC.

Google Cloud Project

VPC Network: internal VPC Network: external

us-west-1 us-west-1

subnet-a-west: 10.100.2.0/24 subnet-a-east: 10.100.1.0/24

34.21.71.3
10.100.2.4 10.100.1.4
External IP

Figure 4: FortiGate VM on Google Cloud.

Deploying a single FortiGate VM on Google Cloud

Customers can deploy FortiGate to secure their environment and apply deep packet inspection to both incoming and
outgoing traffic. In the next section, packet flow in each FortiGate VM deployment scenario is discussed.

North-south traffic inspection

Customers who have adopted both Google Cloud and web applications need to protect their applications against sophisticated
cyberattacks. When deployed in a VPC, FortiGate VM can secure applications by inspecting all inbound traffic originated from
the internet. A common approach in protecting multiple services behind a single FortiGate VM is to map each service IP address/
port to a port and the static IP address associated with the FortiGate public network interface. For example, the web service
in Figure 5 is hosted on port 8080 and is mapped to the FortiGate static IP/port 8080. All traffic destined to the web server is
inspected by the FortiGate VM. The gateway attached to the VPC enables internet connectivity and also performs network
address translation for the private IP address of the FortiGate external interface and the IP associated with that interface.

11
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Internet

67.74.22.78
Source: 67.74.22.78 Source: 34.21.71.3
Dest: 34.21.71.3:8080 Dest: 67.74.22.78
VPC Network: External us-west-1
Gateway subnet-external: 10.100.1.0/24

34.21.71.3

10.100.1.4

Source: 67.74.22.78 Source: 10.100.1.4

Dest: 10.100.1.4:8080 Dest: 67.74.22.78

VPC Network: Internal us-west-1

subnet-internal: 10.100.2.0/24

10.100.2.4
Routing table: VPC_Internal

10.100.2.0/24: local
www.xyz.com:8080 www.xyz.com:8080 www.xyz.com:8080 Source: 67.74.22.78 Source: 10.100.2.5
0.0.0.0/0: 10.0.2.4 Dest: 10.100.2.5:8080 Dest: 67.74.22.78
Web Server Web Server Web Server
10.100.2.5 10.100.2.5 10.100.2.5

Figure 5: Inbound traffic inspection with FortiGate VM.

Figure 5 illustrates the incoming traffic packet flow as well as the path for the return traffic:

Inbound traffic. The gateway translates the destination IP address (which is the static IP associated with the FortiGate
external interface) to the private IP address of the FortiGate internal interface. FortiGate will again apply destination NAT to
change the destination IP address to the IP address of the back-end web server.

Return traffic. Traffic returning from the web server will follow the private subnet route table, which includes a route entry to point
all internet-bound traffic to the FortiGate. As shown in Figure 5, both FortiGate and gateway apply source NAT to the return traffic
to change the source IP to a publicly routable IP address (the static IP associated with the FortiGate external interface).

East-west traffic inspection

FortiGate VM instances are deployed as multiple network interface VMs in Google Cloud. This means FortiGate interfaces can
reside within each of the VPCs to provide east-west traffic inspection and internal segmentation for a typical tiered multi-VPC
environment as shown in Figure 6. In this example, any traffic from the web VPC to application VPC or database VPC goes
through FortiGate. To inspect and secure the traffic from the web VPC server to the application VPC server, firewall policies
with the required security profiles can be defined in FortiGate. The same method applies to communication between the
application server and database server. This design works well for a relatively simple architecture with few VPCs, but cannot
be used across regions.

If the number of VPCs are higher than what a model in Figure 6 can support, or if the VPCs are in different regions, users
can leverage a shared VPC model with VPC peering. With this design, customers can use a combination of VPC peering and
routing to inspect and secure the traffic between the VPCs through FortiGate. The different options for this architecture are
discussed later in this document.

12
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Internet

VPC Network: External us-west-1

Gateway

34.21.71.3

port1
10.100.1.4

subnet-external: 10.100.1.0/24

VPC Network: Web us-west-1 VPC Network: Application us-west-1 VPC Network: Database us-west-1

port1 port2 port3

10.100.4.4 10.100.2.4 10.100.3.4

Web Server App Server DB Server

10.100.4.5 10.100.2.5 10.100.3.5

Routing table: VPC_Web Routing table: VPC_Application Routing table: VPC_Database

10.100.2.0/24: local 10.100.2.0/24: local 10.100.2.0/24: local
0.0.0.0/0 10.0.2.4 0.0.0.0/0 10.0.2.4 0.0.0.0/0 10.0.2.4

subnet-external: 10.100.4.0/24 subnet-Application: 10.100.2.0/24 subnet-Database: 10.100.3.0/24

Figure 6: East-west traffic inspection in Google Cloud using FortiGate VM.

FortiGate Secure SD-WAN overview

As enterprises move to public and hybrid cloud models, they require high-speed, reliable bandwidth for voice, video, internet,
and data applications. With the increase in non-network devices, users, and cloud-based applications, traditional wide-area
networks (WANs) are reaching full capacity and are at a breaking point.

The FortiGate Secure SD-WAN solution is a network application-aware solution that dynamically selects the best WAN link to
maintain the highest SLA. It helps eliminate expensive MPLS solutions and delivers robust resiliency and redundancy.

FortiGate Secure SD-WAN protects application availability and performance across the corporate WAN or across the internet
to multi-cloud environments by leveraging WAN path failover, link aggregation, link remediation, and active path performance
metrics. Essentially, Secure SD-WAN determines which path best meets performance expectations for a particular application
and assigns packets or sessions to that WAN path.

FortiGate Secure SD-WAN has three important components:

SD-WAN interfaces. Physical and virtual interfaces are used to route traffic.

Performance SLAs. Performance SLAs are health checks that are used to monitor member interface link quality and detect
link failures. If the health check fails, the corresponding routes are removed until the health check is successful.

SD-WAN rules. SD-WAN rules are used to control path selection. Specific traffic can be dynamically sent to the best link or
use a specific route. Rules can be configured in one of five available modes which are auto, manual, priority, lowest-cost SLA,
and load balance.

13
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Multi-Cloud

Internet
Private Cloud

Provisioning Threat SIEM & Monitoring and NGFW

Server Intelligence Analytics Management
Data Center

Services
External

NGFW

MPLS

Figure 7: SD-WAN Reference Architecture.

FortiGate integrated NGFW

As explained previously, the FortiGate NGFW provides an extensive set of network security features. With FortiOS providing a
full set of SD-WAN functions, FortiGate delivers a complete Secure SD-WAN solution that is unrivaled in price, performance,
and security effectiveness.

FortiGate application control is a security feature that can detect and defend against network traffic depending on the
application generating the traffic. FortiGate can recognize network traffic generated by a large number of applications based
on its existing application database. In addition, FortiGate allows uers to create custom application signatures to match
custom applications. Since FortiOS security features are fully integrated within Secure SD-WAN, users can also leverage
custom applications in SD-WAN rules.

Since FortiGate can integrate with active directory, SD-WAN policies can be constructed in a way that specific active
directory users/groups have priority routing and best available links for accessing mission-critical resources in the public or
private cloud and internet.

WAN path remediation for business-critical applications

When a FortiGate has IPsec tunnels, these interfaces can be added as SD-WAN member interfaces. When using IPsec tunnels
as SD-WAN interfaces and FortiGate at only one end, they can leverage most of the SD-WAN capabilities of FortiGate. When
a FortiGate is at each end of a VPN tunnel, users can access advanced FortiGate features such as forward error correction.
This feature allows for dynamic remediation of packet loss or erroneous data caused by adverse WAN conditions, as shown in
the example below. This is specifically useful for mission-critical data and/or applications such as Voice over IP (VoIP) that are
prone to packet loss.

14
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Forward Error Correction

Jitter
Buffer

A A

B X Loss

Reconstruct
C C

D D

A B C D IPsec Tunnel A B C D

Original Payload On-premises FortiGate Cluster Recovered Payload

FortiGate in Google Cloud

Figure 8: FortiGate forward error correction.

Dynamic address-based SD-WAN rules

Users can define SD-WAN rules for specific destinations or applications. Fortinet Fabric Connectors are available for
software-defined networking (SDN) in private clouds and for public clouds. The Fabric Connectors enable either FortiGate
or FortiManager to integrate with the third-party SDN or cloud platform to synchronize the dynamic address group objects
that are protected by the FortiGate policy. This is particularly useful when dealing with an elastic environment such as Google
Cloud where the new VMs can be spun up and down automatically. Users can construct SD-WAN rules based on these
dynamic address objects that will ensure on-premises networks have an optimal path to dynamic resources in Google Cloud.

Link aggregation to maximize bandwidth

When an on-premises FortiGate connects with Google Cloud, they typically connect to the cloud VPN gateway using
redundant IPsec tunnels. Otherwise, customers must interconnect in order to connect to Google Cloud. Customers often
leverage Google Cloud as a storage solution, which might include daily/weekly backup of their data from their data center.

The overlay IPsec through interconnect can also be included as an SD-WAN member interface. When the IPsec tunnels are
SD-WAN member interfaces at the data center, customers can distribute traffic across all member interfaces that meet SLA
to maximize the bandwidth utilization during large data transfers from data center to Google Cloud, providing efficient use
of all the available links. This enables the FortiGate to perform per-packet load balancing between the tunnel interfaces that
are members of the SD-WAN interface.

Design Pattern/Deployment Scenarios Using FortiGate for Google Cloud Multi-VPC Connectivity
Due to the complexity of cloud deployments, customers do not have a single VPC/single project architecture within Google
Cloud. In a production Google Cloud deployment, the resources are spread across multiple VPCs in multiple projects that
can span multiple regions to account for proper segmentation and fault tolerance.

Customers can leverage the shared VPC model and VPC network peering for a low-latency and cost-effective method for
VPC connection. This communication occurs over the RFC 1918 address space, meaning it is not exposed to the internet.

In hybrid cloud deployments, customers will have some services and applications hosted in Google and others in their on-
premises network. Customers need an easy, secure way to access all of their resources in the Google Cloud environment
from their on-premises networks.

A hub VPC can act as a hub where multiple VPCs connect and where on-premises network connection terminates. This
configuration enables a secure connectivity between the on-premises network and the hub VPC. Then, it can be extended
to other peered VPCs. The connectivity from the on-premises environment could be a cloud VPN to the cloud VPN gateway,
or a dedicated interconnect link to the cloud router in the hub VPC. There are multiple architectures that can be used for
this secure hybrid connectivity.

15
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

VPN from on-premises FortiGate to cloud router in hub VPC through the internet
One way to securely connect on-premises networks to the hub VPC is through an IPsec VPN. In the architecture shown in
Figure 9, FortiGate is used to establish redundant VPN connections to the cloud VPN gateway in Google Cloud. Once this
connectivity is established, BGP is used to dynamically exchange routing information between the Google Cloud cloud
router and the FortiGate on-premises network. The hub VPC route table establishes the routes to all on-premises networks
listed by FortiGate. In turn, the on-premises FortiGate will have routes to the networks in the hub VPC.

When VPC peering is established between the hub VPC and peer VPC, users can import and export all of the default VPC
routes or custom routes between the two peers. When importing/exporting custom routes, the hub VPC BGP routes will
also be imported into the spoke VPC. The spoke VPC routes will also be exported into the hub VPC route table.

The hub VPC route table will then have routes to the peer VPCs and on-premises network. The spoke VPC route table also
has routes to the hub VPC networks and on-premises networks. BGP peering between the FortiGate and the cloud router
will enable FortiGate with the routes to the hub VPC peered VPC networks as well.

If additional VPCs are peered to the hub VPCs through route import/export and BGP, new network peers will also have
connectivity to the on-premises networks.

BGP Session 0 169.254.0.1

BGP Session 1 169.254.1.1

Google Cloud Project

VPC Network: spoke-1 VPC Network: Hub VPC

us-central-1
VPN Tunnels 0 and 1
Routing table Routing table HA Cloud VPN Gateway
10.88.0.0/16: local 10.100.0.0/16: local VPN Tunnels 2 and 3
VPC Peering ha-vpn-gw-a
10.100.0.0/16: peer 10.88.0.0/16: peer
192.168.119.0/24: peer 192.168.119.0/24: peer
BGP
192.168.222.0/24: peer 192.168.222.0/24: peer
Cloud Router 169.254.2.1
router-a (ASN 65112) BGP 169.254.3.1

us-west-1 us-east-1 BGP Session 2

BGP Session 3
subnet-a-west: 10.88.1.0/24 subnet-a-east: 10.100.2.0/24 subnet-a-central: 10.100.1.0/24
Import

Resources
routes
Resources Resources
Internet

External IP and
BGP IP 169.254.0.2
BGP IP 169.254.1.2
External IP and
BGP IP 169.254.1.2 WAN 2 WAN 1
BGP IP 169.254.3.2 SD-WAN NGFW

On-premises Network FortiGate

NGFW
Routing table
10.100.0.0/16: bgp
10.88.0.0/16: bgp
192.168.119.0/24: local
On-premises subnets
Int7: 192.168.222.1 Int5: 192.168.119.1 192.168.222.0/24: local
(ASN 7224)

Figure 9: VPN from FortiGate to cloud router in Google Cloud.

Once the IPsec VPNs and BGP are established between the on-premises FortiGate and the cloud VPN gateway/cloud router
in the shared VPC, users will have seamless access from on-premises networks to all peered VPCs.

Redundant internet connections on-premises means there would be redundant VPN tunnels from each of the WAN interfaces.
There are four VPN tunnels in total. They provide highly redundant VPN connectivity to the Google Cloud networks.

This also provides the flexibility to use SD-WAN capabilities on-premises. Users can prioritize mission-critical applications
across the VPN tunnel with the lowest latency and highest throughput. They can also prioritize data based on specific users/
groups determined by active directory membership and/or roles within the organization. FortiGate NGFW features can be
added on top of the SD-WAN interfaces, providing highly secure SD-WAN connectivity to Google Cloud.

16
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

VPN from on-premises FortiGate to FortiGate cluster in hub VPC(s)

Figure 9 displays a clear need for Layer 7 inspection and threat intelligence in the Google Cloud environment. Figure 10
includes the FortiGate A-P HA cluster in the hub VPC, which provides threat intelligence along with dynamic routing and
VPN termination. It can be used to replace the cloud router and cloud VPN gateway. The same FortiOS runs on the cloud
FortiGate cluster, which provides single-pane-of-glass management via FortiManager.

Google Cloud Project

VPC Network: spoke-2 VPC Network: Internal VPC Network: External

us-west-1 us-west-1
Routing table
subnet-internal: 10.100.2.0/24 subnet-external: 10.100.1.0/24
10.77.0.0/16: local
10.100.1.0/24: peer VPC Peering
Tunnel 0 Interface
10.100.2.0/24: peer 172.31.1.1 VPN Tunnel 0

Clulster IP
192.168.119.0/24: peer ILB 10.100.2.4 10.100.1.4
FortiGate
192.168.222.0/24: peer Instance Group VPN Tunnel 1

10.100.2.10 Tunnel 1 Interface

172.31.2.1
Cluster IP
10.100.2.5 10.100.1.5 35.86.117.23
us-west-1
Routing table Routing table
subnet-a-west: 10.77.1.0/24 Import 10.100.2.0/24: local 0.0.0.0/0: 10.100.1.1
routes 0.0.0.0/0:
192.168.119.0/24:
ILB
ILB
10.77.0.0/16:
192.168.119.0/24:
10.100.2.1
bgp
Internet
Resources 192.168.222.0/24: ILB 192.168.222.0/24: bgp
10.0.77.0/16: peer

External IP and
BGP IP 172.31.1.2

External IP and
BGP IP 172.31.2.2
WAN 2 WAN 1
SD-WAN NGFW

On-premises Network FortiGate

NGFW
Routing table
10.100.2.0/24: bgp
10.77.0.0/16: bgp
192.168.119.0/24: local
On-premises subnets
Int7: 192.168.222.1 Int5: 192.168.119.1 192.168.222.0/24: local
(ASN 7224)

Figure 10: VPN from FortiGate to FortiGate cluster in Google Cloud.

The hub VPC construct differs in this deployment method. In this scenario, instead of one central hub VPC, there are two
VPCs. One internal VPC is used for peering the relevant customer VPCs on the Google Cloud side. This VPC can act as a
transit for both internet-bound traffic and also for traffic destined to on-premises networks. The peered VPCs ingest the
route table from the internal VPC. The external VPC handles the VPN termination and BGP routing.

In Figure 10, the new Google Cloud internal load balancer is utilized for HA for internet-bound traffic and traffic destined to
on-premises networks. FortiGate instances are placed in an instance group to support this architecture.

A typical FortiGate NGFW cluster deployment has at least two interfaces, each of which resides in a different VPC. The
external/internet-facing interfaces are placed in the external VPC. The internal interfaces are in an internal VPC. The VPCs
that need to be peered for on-premises connectivity are peered to the internal VPC. Since the VPN and BGP are terminated
directly at the FortiGate cluster, the BGP routes are not ingested into the external or internal VPC route tables. The routes to
the on-premises networks would not be imported in to the peered VPCs automatically.

To achieve end-to-end connectivity, create route entries for the on-premises network in the internal VPC route table and
import/export them with peering via spoke VPCs. This presents an option to create route filtering at the internal VPC level. In
addition, appropriate routing on the FortiGate cluster is needed for routing to the spoke VPCs. For example, the routes were
created to the network 192.168.119.0/24 and 192.168.222.0/24 through the internal load balancer of the internal VPC.

The VPN termination from the two internet connections on the on-premises side terminates on a single static IP address on
the Google Cloud side. The two VPN tunnels in this case will be the member interfaces of the SD-WAN interface. Intelligent
packet routing over these links can happen based on the SLA that is configured. FortiGate NGFW features along with the
built-in Secure SD-WAN provides a protected connection to Google Cloud networks.

17
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

VPN from on-premises FortiGate to FortiGate cluster in hub VPC(s) through interconnect
In the first two scenarios, the VPN connection from the on-premises FortiGate to cloud VPN gateway, or FortiGate VM
in Google Cloud, happens over the public internet. Interconnect is a great option for businesses that are seeking secure,
ultralow latency connectivity into Google Cloud’s networks. Interconnect bypasses the public internet and establishes a
secure, dedicated connection from the infrastructure into Google Cloud networks. There are two types of interconnect:

Dedicated interconnect provides direct physical connections between the on-premises network and Google Cloud
network. It enables customers to transfer large amounts of data between networks, which can be more cost-effective than
purchasing additional bandwidth over the public internet.

Partner interconnect provides connectivity between the on-premises network and VPC network through a supported
service provider. A partner interconnect connection is useful if the customer’s data center is in a physical location that
cannot reach a dedicated interconnect colocation facility, or if data needs do not warrant an entire 10 Gbps connection.

When interconnect is used, the architecture for shared VPC differs slightly from the previous architectures. Once the
external VPC and the on-premises networks have connectivity through interconnect, customer VPCs can be peered to the
external VPC and end-to-end connectivity can be achieved. However, the FortiGate is needed to enable NGFW features.

Google Cloud Project

VPC Network: spoke-2 VPC Network: Internal VPC Network: External

us-west-1 us-west-1
Routing table
subnet-internal: 10.100.2.0/24 subnet-external: 10.100.1.0/24
10.77.0.0/16: local
10.100.1.0/24: peer VPC Peering
Tunnel 0 Interface VPN Tunnel 0

Clulster IP
10.100.2.0/24: peer
ILB
192.168.119.0/24: peer 10.100.2.4 10.100.1.4 Tunnel 1 Interface VPN Tunnel 1
192.168.222.0/24: peer
10.100.2.10
Cluster Private IP
10.100.2.5 10.100.1.5 10.100.1.10

FortiGate
169.254.0.1
Cloud Router
us-west-1 Instance Group router-a
169.254.1.1
(ASN 65112)
Routing table
subnet-a-west: 10.77.1.0/24 Import 10.100.2.0/24: local
FortiGate Routing table
Cloud
routes 0.0.0.0/0: ILB
192.168.119.0/24: ILB
0.0.0.0/0:
10.77.0.0/16:
10.100.1.1
10.100.2.1
Interconnect
Resources 192.168.222.0/24: ILB
192.168.119.0/24: bgp
10.0.77.0/16: peer
192.168.222.0/24: bgp

External IP and
BGP IP 169.254.0.2

External IP and
BGP IP 169.254.1.2
WAN 2 WAN 1
SD-WAN NGFW

On-premises Network FortiGate

NGFW
Routing table
10.100.2.0/24: bgp
10.77.0.0/16: bgp
192.168.119.0/24: local
On-premises subnets
Int7: 192.168.222.1 Int5: 192.168.119.1 192.168.222.0/24: local
(ASN 7224)

Figure 11: VPN from FortiGate to FortiGate cluster in Google Cloud through interconnect.

In the architecture shown in Figure 11, internal VPC is used for peering the relevant customer VPCs on the Google Cloud side.
This VPC can act as a transit for both internet-bound traffic and also the traffic destined to the on-premises networks. The
peered VPCs ingest the route table from this internal VPC. The new Google Cloud internal load balancer is used for HA for
internet-bound and on-premises traffic.

A typical FortiGate NGFW cluster deployment has at least two interfaces, each of which resides within a different VPC. Just
like the previous architecture, the external/internet-facing interfaces of the FortiGate cluster are placed in the external VPC,
and the internal interfaces are placed in an internal VPC. The VPCs that need to be peered for on-premises connectivity are
peered to the internal VPC.

18
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

The external VPC has the cloud router with which the on-premises FortiGate forms a BGP relationship and exchanges routes.
Once the connectivity is established, an overlay VPN across the interconnect is formed between the on-premises FortiGate and
the FortiGate cluster in Google Cloud. BGP peering occurs between the on-premises FortiGate and FortiGate cluster over IPsec
VPN and the routes are exchanged. This provides end-to-end connectivity from the spoke VPCs to the on-premises networks.

The route exchange between the spoke VPCs and internal VPC, and the way in which spoke VPC routes are ingested into
the FortiGate cluster, follow the same pattern as the previous architecture shown in Figure 10.

The VPN termination from the two internet connections on the on-premises side terminates on a single static IP address
on the Google Cloud side. In this architecture, the on-premises FortiGate has two VPN tunnels that are part of the Secure
SD-WAN interfaces. Secure SD-WAN policies leverage these links for intelligent application routing based on SLAs defined
for the latency, jitter, and throughput across different IPsec tunnels. With FortiGate on both sides, users achieve additional
features such as forward error correction for sensitive applications such as VoIP. When there is a big file transfer from on-
premises to the Google Cloud network for backup, the SD-WAN member interfaces can be aggregated to utilize both the
available links to Google Cloud.

Connect GKE on-premises and GKE using FortiGate Secure SD-WAN

In addition to providing secure connectivity between on-premises and Google Cloud VPCs, Fortinet Secure SD-WAN can
be leveraged to connect multi-cloud deployments. This can include physical, virtualized, and containerized workloads
including Google Anthos deployments.

Anthos provides a consistent development and operations experience for cloud and on-premises environments. Anthos
provides a state-of-the-art container management platform based on Kubernetes. Developers can use this platform to
quickly and easily build and deploy existing container-based applications and microservices-based architectures. It is
composed of multiple products and features:

Google Kubernetes Engine (GKE). Anthos relies on GKE to manage Kubernetes installations in the environments where users
intend to deploy their applications. With GKE, the control plane is managed by Google Cloud but the worker nodes can be
accessed directly by users. With GKE on-premises, all components are hosted in the customer’s on-premises environment.

Enterprise Data Center

Istio Service
Google Cloud Project
Mesh

VPC Network: internal VPC Network: external

Secure
us-central-1 us-central-1
SD-WAN

Management
Anthos Config
Secure SD-WAN
Anthos
Service Mesh
Anthos Config

IPsec
Cluster IP
Management

Internet ISP2 ISP1

IPsec
GKE
On-Prem
Google
Kubernetes Engine
IPsec

IPsec

AWS Cloud
Cluster IP

VPC

Secure SD-WAN

Figure 12: Connect GKE on-premises and GKE using FortiGate Secure SD-WAN.

19
WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Reference Architecture

Configuration management. Centralized configuration management and compliance can be achieved with configuration-
as-code and Anthos configuration management.

Service mesh. Anthos service mesh can manage a customer’s Istio environments.

To take advantage of the full functionality provided by Anthos, a customer’s GKE and GKE on-premises clusters need IP
connectivity among them. FortiGate Secure SD-WAN can connect both on-premises and cloud GKE. As shown in Figure 12,
customers can create VPN IPsec tunnels between FortiGate appliances deployed on-premises and FortiGate VM on Google
Cloud to achieve advanced security and powerful Secure SD-WAN features.

Conclusion
As public cloud adoption accelerates, integration with Google Cloud native connectivity is of paramount importance.
Google Cloud customers can use FortiGate in their hybrid cloud and multi-cloud environments to connect workloads and
applications deployed across the cloud and on-premises. FortiGate Secure SD-WAN enables organizations to securely
and intelligently connect their on-premises and cloud environments. Additionally, customers who prefer to use the Google
Cloud native cloud VPN service can still take advantage of FortiGate Secure SD-WAN features by establishing IPsec tunnels
between Google Cloud VPN and FortiGate devices deployed in their data centers and connecting workloads. With NGFW
capabilities, high-performance VPN functionality, and powerful Secure SD-WAN features, FortiGate provides Google Cloud
customers with end-to-end protection.

www.fortinet.com

Copyright © 2021 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product
or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other
conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser
that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any
such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise
revise this publication without notice, and the most current version of the publication shall be applicable.

August 9, 2021 8:32 PM

568174-A-0-EN