FortiGate Secure SD-WAN on Google Cloud Platform (GCP ...€¦ · The public cloud, often referred to as the cloud, is a popular model of cloud computing. Cloud service providers

FortiGate Secure SD-WAN on Google Cloud Platform (GCP) Reference Architecture

WHITE PAPER

2

WHITE PAPER | FortiGate Secure SD-WAN on Google Cloud Platform (GCP) Reference Architecture

Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

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

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

Key GCP 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 GCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

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

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

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

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

FortiGate VM deployment on GCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3


Table of Contents

Deploying a single FortiGate VM on GCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 ForiGate for GCP 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

4

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 multi-tenant 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.

Figure 1: The shared responsibility model.

5


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.

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 Platform (GCP) 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 GCP—along with powerful 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 GCP Concepts

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

Regions and zones

A zone is a deployment area for GCP resources. It is the finest grained GCP infrastructure construct that users can specify when deploying GCP 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 GCP customers deploy their applications in more than one region to protect against the loss of an entire region due to natural disasters.

Figure 2: GCP regions and zones.

6


Organization

The Google Cloud resource hierarchy includes an optional organization resource and folders. This allows companies to map their organization onto Google Cloud and provide logical attach points for access management policies (Cloud IAM) and organization policies. The organization resource is the root node in the Google Cloud resource hierarchy, and provides centralized visibility and control over every resource that belongs to an organization.

Folders

Folders are a group of projects and subfolders that provide logical separation within 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

Customers should consider their overall network map before creating VPCs and defining classless inter-

domain routing (CIDR) to them just as when assigning CIDRs in

physical data centers. This will help avoid issues such as IP address overlapping after instances are

deployed in GCP.

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 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 GCP 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 GCP 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.

GCP 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 GCP 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.

https://cloud.google.com/resource-manager/docs/organization-policy/overview

https://cloud.google.com/resource-manager/reference/rest/v1/organizations

7


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:

n 10.1.7.0: Network address

n 10.1.7.1: Default gateway

n 10.1.7.254: Reserved by GCP for potential future use

n 10.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:

n Default 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.

n Subnet 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, GCP 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:

n Static routes are often created manually to steer traffic to a static route next hop such as an instance.

n Dynamic 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 to 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.

8


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.

Figure 3: GCP VPC networking.

9


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 GCP.

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.

GCP 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:

n Priority 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.

n Direction of traffic is determined by ingress and egress rules. Ingress rules apply to incoming connections from specified sources to GCP targets, and egress rules apply to traffic going to specified destinations from targets.

n An action with either allow or deny options will determine if the rule permits or blocks traffic.

n A target defines the instances to which the rule will apply.

n A source applies to ingress rules and a destination applies to egress rules.

n A protocol (such as TCP, UDP, or ICMP) and port.

Cloud VPN

Cloud VPN securely connects a customer’s peer network to their GCP VPC through an IPsec connection. GCP 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 GCP VPC network through an IPsec VPN connection in a single region. HA VPN provides an SLA of 99.99% service availability. When a user creates an HA VPN gateway, GCP 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 GCP 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 GCP

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 GCP and helps customers secure their cloud architecture.

In addition, FortiGate VM provides IPsec VPN, 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 GCP to identify and mitigate the latest and most complex cyber threats.

FortiGate VM on GCP can:

n Protect against known exploits and malware using continuous threat intelligence provided by FortiGuard Labs security services.

n Achieve visibility into all types of traffic across the cloud with secure sockets layer (SSL) inspection.

10


n Identify thousands of applications including cloud applications for deep inspection into network traffic.

n Protect against unknown attacks using dynamic analysis, providing automated mitigation to stop targeted attacks.

FortiManager

FortiManager virtual security management appliances for GCP 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 GCP 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 GCP 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 GCP instances.

Instance type support

FortiGate VM supports the following instance types on GCP:

FortiGate for GCP 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:

Table 1. FortiGate VM models (BYOL)

Table 1: FortiGate VM models (BYOL).

vCPU Maximum

1

2

4

8

16

32

Unlimited

Model Name

FG-VM01/01v/01s

FG-VM02/02v/02s

FG-VM04/04v/04s

FG-VM08/08v/08s

FG-VM16/16v/16s

FG-VM32/32v/32s

FG-VMUL/ULv/ULs

vCPU Minimum

1

1

1

1

1

1

1

https://cloud.google.com/compute/docs/machine-types#predefined_machine_types

11


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 GCP

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

Deploying a single FortiGate VM on GCP

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 GCP 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.

Figure 4: FortiGate VM on GCP.

12


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 GCP. 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.

Figure 5: Inbound traffic inspection with FortiGate VM.

13


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.

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

14


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.

15


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 GCP 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 GCP.

Link aggregation to maximize bandwidth

When an on-premises FortiGate connects with GCP, they typically connect to the cloud VPN gateway using redundant IPsec tunnels. Otherwise, customers must interconnect in order to connect to GCP. Customers often leverage GCP 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 GCP, 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 GCP Multi-VPC Connectivity

Due to the complexity of cloud deployments, customers do not have a single VPC/single project architecture within GCP. In a production GCP 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 GCP 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.

Figure 8: FortiGate forward error correction.

16


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 GCP. Once this connectivity is established, BGP is used to dynamically exchange routing information between the GCP 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.

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 GCP 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 GCP.

Figure 9: VPN from FortiGate to cloud router in GCP.


17

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 GCP 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.

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 GCP 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 GCP 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 GCP 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 GCP networks.

Figure 10: VPN from FortiGate to FortiGate cluster in GCP.


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 GCP, happens over the public internet. Interconnect is a great option for businesses that are seeking secure, ultralow latency connectivity into GCP’s networks. Interconnect bypasses the public internet and establishes a secure, dedicated connection from the infrastructure into GCP networks. There are two types of interconnect:

Dedicated interconnect provides direct physical connections between the on-premises network and GCP 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.

In the architecture shown in Figure 11, internal VPC is used for peering the relevant customer VPCs on the GCP 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 GCP 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.

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 GCP. 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.

18

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


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 GCP side. In this architecture, the on-premises FortiGate has two VPN tunnels that are part of the Secure SD-WAN interfaces. Secure SDWAN 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 GCP network for backup, the SD-WAN member interfaces can be aggregated to utilize both the available links to GCP.

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

In addition to providing secure connectivity between on-premises and GCP 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 GCP 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.

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 GCP to achieve advanced security and powerful Secure SD-WAN features.

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

19


Conclusion

As public cloud adoption accelerates, integration with GCP native connectivity is of paramount importance. GCP 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 GCP native cloud VPN service can still take advantage of FortiGate Secure SD-WAN features by establishing IPsec tunnels between GCP 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 GCP customers with end-to-end protection.

Copyright © 2019 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. 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.

www.fortinet.com

December 13, 2019 9:16 AM

Macintosh HD:Users:ckluck:Documents:FORTINET_ck:2019:wp-GCP:final:wp-GCP568174-0-0-EN