Workshop Logistics

Accessing an AWS environment

For the FortiGate CNF Tec Recipe, you will need the following:

• AWS sign in link
• IAM User w/ console access
• Password for the IAM User

Accessing the FortiGate CNF Console

FortiGate CNF and other SaaS solutions are tied to your FortiCloud. If you do not already have one, please navigate here and complete the registration process.

Once logged in, you will see your FortiCloud dashboard.

You will log into the FortiGate CNF console later during the hands on section.

Navigating the AWS Console

When you first login you will see the Console Home page.

Use the Search Box at the top to search for services such as EC2, VPC, Cloud Shell, etc.

When the results pop up, right click the name of the service and open the desired console in a new tab. This makes navigation easier.

AWS Networking Concepts

Before diving into the reference architecture for this workshop, let’s review core AWS networking concepts.

AWS Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

Availability zones (AZ) are multiple, isolated locations within each Region that have independent power, cooling, physical security, etc. A VPC spans all of the AZs in the Region.

Region, is a collection of multiple regional AZs in a geographic location. The collection of AZs in the same region are all interconnected via redundant, ultra-low-latency networks.

All subnets within a VPC are able to reach each other with the default or intrinsic router within the VPC. All resources in a subnet use the intrinsic router (1st host IP in each subnet) as the default gateway. Each subnet must be associated with a VPC route table, which specifies the allowed routes for outbound traffic leaving the subnet.

An Internet Gateway (IGW) is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet. It therefore imposes no availability risks or bandwidth constraints on your network traffic.

AWS NAT Gateway (NAT GW) is a Network Address Translation (NAT) service. You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services cannot initiate a connection with those instances.

AWS Transit Gateway (TGW) is a highly scalable cloud router that connects your VPCs in the same region to each other, to on-premise networks, and even to the internet through one hub. With the use of multiple route tables for a single TGW, you can design hub and spoke routing for traffic inspection and enforcement of security policy across multiple VPCs.

AWS (Gateway Load Balancer (GWLB) is a transparent network gateway that distributes traffic (in a 3/5 tuple flow aware manner) to a fleet of virtual appliances for inspection. This is a regional load balancer that uses GWLB endpoints (GWLBe) to securely intercept data plane traffic within consumer VPCs in the same region.

In this workshop we will use all these components to test FortiGate CNF in an enterprise design.

AWS Common Architecture Patterns

While there are many ways to organize your infrastructure, there are two main ways to design your networking when using GWLB:

• centralized
• distributed.

We will discuss this further below.

FortiGate CNF is a SaaS offering that on the backend uses FortiGates, AWS GWLB, and GWLB endpoints to intercept customer traffic and inspect this traffic transparently. As part of the deployment process for FortiGate CNF instances, the customer environment will need to implement VPC and ingress routing at the IGW to intercept the traffic to be inspected.

The FortiGate CNF security stack, which includes the AWS GWLB and other components, will be deployed in Fortinet managed AWS accounts. The details of the diagram are simply an example of the main components used in FortiGate CNF.

The following diagrams and paragraphs will explain what happens when customer traffic is received at the FortiGate CNF GWLB.

Decentralized designs do not require any routing between the protected VPC and another VPC through TGW. These designs allow simple service insertion with minimal routing changes to the VPC route table. The yellow numbers show the initial packet flow for a session and how it is routed (using ingress and VPC routes) to the GWLBe endpoint which then sends traffic to the FortiGate CNF stack. The blue numbers show the returned traffic after inspection by the FortiGate CNF stack.

Note: Any subnet where the GWLBe for the FortiGate CNF instance is to be deployed will need to have a specific tag name and value to be seen in the FortiGate CNF portal. Currently this is the tag name ‘fortigatecnf_subnet_type’ and tag value ‘endpoint’.

Centralized designs require the use of TGW to provide a simple hub and spoke architecture to inspect traffic. These can simplify east-west and egress traffic inspection needs while removing the need for IGWs and NAT Gateways to be deployed in each protected VPC for egress inspection. You can still mix a decentralized architecture to inspect ingress and even egress traffic while leveraging the centralized design for all east-west inspection.

The yellow numbers show the initial packet flow for a session and how it is routed (using ingress, VPC routes, and TGW routes) to the GWLBe which then sends traffic to the FortiGate CNF stack. The blue numbers (east-west) and purple numbers (egress) show the returned traffic after inspection by the FortiGate CNF stack.

For more examples of distributed and centralized models, please reference the examples on the FortiGate CNF Admin Guide.

FortiGate CNF Terminology

Task 1: Install Terraform in AWS Cloudshell

• Log into your AWS account and navigate to the Console Home.
• Click on the AWS CloudShell icon on the console navigation bar

• We are going to use the Terraform Version Manager to help install Terraform

• Clone the Terraform Version Manager repository

  git clone https://github.com/tfutils/tfenv.git ~/.tfenv

• Make a new directory called ~/bin

  mkdir ~/bin

• Make a symlink for tfenv/bin/* scripts into the path ~/bin

  ln -s ~/.tfenv/bin/* ~/bin

• With the Terraform Version Manager installed, we can now install Terraform.

  tfenv install

  

• This will install the latest version of Terraform for you. Take note of the installed version of terrform. In this case, the default version is 1.5.3.

• To make this version the default version, use the following commmand

  tfenv use 1.5.3

• Verify you are using the proper version of terraform

  terraform -v

  

• This concludes this section.

Task 2: Create Distributed Workload VPC using Terraform in AWS Cloudshell

• Log into your AWS account and navigate to the Console Home.

• Click on the AWS CloudShell icon on the console navigation bar

• Clone a repository that uses terraform to create a distributed ingress workload vpc

  git clone https://github.com/FortinetCloudCSE/FortiGate-AWS-CNF-TEC-Workshop.git

• Change directory into the newly created repository for distributed_ingress_nlb

  cd FortiGate-AWS-CNF-TEC-Workshop/terraform/distributed_ingress_nlb

• Copy the terraform.tfvars.example to terraform.tfvars

  cp terraform.tfvars.example terraform.tfvars

• Edit the terraform.tfvars file and insert the name of a valid keypair in the keypair variable name and save the file

• Use the “terraform init” command to initialize the template and download the providers

  terraform init

• Use “terraform apply –auto-approve” command to build the vpc. This command takes about 5 minutes to complete.

terraform apply --auto-approve

• When the command completes, verify “Apply Complete” and valid output statements.
  • Make note of the Web Url (red arrow) for each instance and for the NLB that load balances between the Availability Zones.
  • Make note of the ssh command (yellow arrow) you should use to ssh into the linux instances.
  • Write down the Public IP address of the linux instance in AZ1. We are going to use that IP for our CNF external syslog server when we deploy Fortigate CNF.
  • Bring up a local browser and try to access the Web Url. It will fail because these Web Servers are vulnerable and the security group only allows ssh (tcp port 22). We will fix this in the next task.
  • Copy the “Outputs” section to a scratchpad. We will use this info throughout this workshop.

The network diagram for the distributed ingress vpc looks like this:

• This concludes this section.

IaC Discussion Points

Discussion Points During a Demo - Chapter 3

Fortinet provides a large library of infrastructure as code (IaC) templates to deploy baseline and iterate POC and production environments in public cloud. IaC support includes Terraform, Ansible, and cloud-specific services such as Azure ARM, AWS Cloudformation, and Google Deployment templates. Terraform Providers are available for several Fortinet products to insert and iterate running configuration.

For more information, review the following:

• FortiOS 7.2 Admin Guide

• Terraform Providers

• Ansible Modules

Advantages of Using AWS CloudShell for Deployment

AWS CloudShell is a browser-based shell that makes it easy to securely manage, explore, and interact with your AWS resources. CloudShell is pre-authenticated with your console credentials and common development and operations tools are pre-installed. CloudShell is available in all commercial AWS regions at no additional cost and provides an environment with preconfigured CLI tools and access to AWS services. CloudShell provides a temporary 1 GB storage volume that is deleted after 120 minutes of inactivity. CloudShell is a convenient method to deploy IaC templates for demonstrations and quick deployments.

Alternative Methods of using Terraform in Production Environments

AWS Cloudshell is a nice environment for deploying demo environments. However, for production environments, it is recommended to use a local workstation or a CI/CD pipeline. If your customer is asking about how to deploy Terraform in production, you can point them to the following resources:

• https://aws.amazon.com/blogs/apn/terraform-beyond-the-basics-with-aws/

Be sure to point out that the Fortinet Terraform templates are free to use and modify. These templates are designed to illustrate reference architectures in a demo environment only and may require modification to meet production requirements.

Key questions during your demo

When giving this TEC Workshop as a demo, the following questions will provide a basis for next steps and future meetings:

• Has your organization standardized on an IaC tool-set for infrastructure provisioning and iteration?
• How are the responsibilities for infrastructure assigned? Does cloud network fall under a DevOps, Cloud Networking, or Application Delivery team, as examples?
• What is organizations view on how IaC can improve workflows?
• Is workflow automation in cloud and cross-organizational collaboration important within your cloud business?

Task 3: Protect the Workload VPC with Security Group Rules

The network diagram for the distributed ingress vpc looks like this:

• Let’s take a look at the security group for the linux instance.
  • From Console Home, click on EC2
  • From EC2, click on Instances (running)
  • Choose the instance in AZ1
  • Click on the security tab for the instance
  • Click on the link to the security group

• On this screen, we can see that we are allowing SSH (tcp port 22) and HTTP (tcp port 80) from any IPv4 address. The instance is protected from login by the ssh keypair, but let’s tighten the security up using the security group to prevent random access to the Apache server.
  • Click on “Edit Inbound Rules” (yellow arrow)

• Click on the “Source” dropdown and change “Anywhere-IPv4” to “My IP” for the Inbound HTTP and Inbound SSH.
• Change the description from Anywhere to My IP
• Click “Save Rules”

• Now we have security rules to access our linux instances via SSH and HTTP from our Public IP.

• We also have security rules that allow HTTP and SSH via the NLB to have access to the linux instances. The NLB has a Public IP in each AZ. This allows us to access the backend servers through the NLB and the access will be load balanced across each AZ.

• We also allowed the CNF instance to use the instance as a Syslog Server. In this workshop, both instances use the same security group, so there is no need to make the same changes to the security group on the second instance.

• Lookup the “Public IP” associated with each linux instance and bring up a browser to verify connectivity. You should see a slightly modified Default Apache2 Page that also shows the AZ of the response linux instance.

• This was a small demonstration on managing security policy with security groups. A bit tedious don’t you think? Now let’s deploy a Fortigate CNF instance and manage security policy with a Next Generation Firewall.

• This concludes this section.

Managing Security with AWS Security Groups - Discussion Points

Discussion Points During a Demo - Chapter 4

Key reasons for using a Next Generation Firewall in the cloud:

• AWS Security Groups are static and do not provide dynamic security policies that can keep up with the dynamic nature of cloud infrastructure.
• Building dynamic policies with AWS Security Groups is a manual process that is not scalable.
• AWS Security Groups do not use threat intelligence to block known bad IP addresses and new or unknown threat vectors like a Next Generation Firewall does.
• Updating AWS Security Groups across a large deployment is prone to error and omission.
• AWS Security Groups are not managed through a single pane of glass across multi-cloud and on-premises environments.

Key questions during your demo

When giving this TEC Workshop as a demo, the following questions will point out that AWS Security Groups are not dynamic enough to keep up with changing cloud infrastructure and do not inspect the traffic at layers 4-7 like a Next Generation Firewall does:

• Do you plan to provide deep inspection of traffic in your cloud environment? Security Groups are limited to layer 4 inspection only. FortiGate firewalls can apply UTM inspection profiles to traffic flows and protect against a wide range of new or unknown threat vectors.
• Do you plan to provide dynamic security policies that can keep up with the dynamic nature of cloud infrastructure? Security Groups are static and do not provide dynamic security policies. FortiGate objects can be dynamically built and updated based on tags and other attributes that scales with a changing cloud infrastructure.
• Do you plan to provide a single pane of glass for security policy management across your cloud and on-premises environments? Security Groups are limited to AWS only and do not provide a single pane of glass for security policy management across multi-cloud and on-premises environments.

Task 4: Subscribe to FortiGate CNF in AWS Marketplace

• Log into your AWS account and navigate to the AWS Marketplace listing for FortiGate CNF. In the upper right corner, click View purchase options. On the next page, click Subscribe.

• In the available offers list, select the Public offer.

• The page should update and show the GA pricing. Click Subscribe.

• A green banner will be at the top of the screen. Click Set up your account and this will redirect you to associating this subscription to your FortiCloud account.

• If you do not already have a FortiCloud account*, the Register button will navigate you to where you can create your own account quickly. Otherwise move on to the next step and login to your existing FortiCloud Account.

• You should see this page showing your information and that the subscription has been successfully applied to your FortiCloud account.

• Click on your account tile and you will now be on the dashboard of FortiGate CNF.

• This concludes this section.

Task 5: Onboard an AWS account to FortiGate CNF

• In the FortiGate CNF Console, navigate to AWS Accounts, then click New to start the add account wizard.

• In a new browser tab, log into your AWS account and click on your IAM user name in the upper right corner. This will allow you to see and copy your AWS account ID.

• In the FortiGate CNF Console, provide your AWS account ID and select Launch CloudFormation Template. This will redirect you to the CloudFormation Console in your AWS account in the us-west-2 region.

• This CloudFormation Template creates the following items:

  • S3 bucket for sending logs

  • IAM Cross Account Role which allows us to manage GWLBe endpoints, describe VPCs, push logs to S3, and describe instances and EKS clusters for the SDN connector feature (dynamic address objects based on metadata).

  • Custom resources which kicks off automation on our managed accounts to complete backend tasks for onboarding the AWS account.

• Please follow through the create stack wizard without changing the region or any of the parameter values. Simply follow the steps outlined in the FortiGate CNF Console and click through the CloudFormation wizard.

• Once the CloudFormation template has been created successfully, you should see your account showing Success in the AWS account page of FortiGate CNF.

• This concludes this section.

Task 6: Deploying CNF Instances and GWLBe endpoints

• In the FortiGate CNF console, navigate to CNF instances and click New.
• Take note of the Linux AZ1 Public IP for the Workload VPC. Look for the following output in your scratch file. You will need this later.

• Provide a name for the CNF instance, select us-west-2 for the region for deployment, select External Syslog for the log type, and insert the Linux AZ1 Public IP you wrote down earlier when you created the Workload VPC. Then click OK at the bottom. This will drop you back to the list of CNF instances while this is deployed in the background.

• us-east-1 (N. Virginia)
• us-east-2 (Ohio)
• us-west-1 (N. California)
• us-west-2 (Oregon)
• eu-central-1 (Frankfurt)
• eu-west-1 (Ireland)
• ap-northeast-1 (Tokyo)

• The CNF Instance should show up as active after roughly 10 minutes (Now is a great time for a break :) ). Then you can select and edit it to deploy endpoints and assign a policy set.

• On the Configure Endpoints section of the wizard, click the New button. Then you can select the account, VPC, then toggle the Select from all subnets to off (this filters the subnets to only show ones that are properly tagged), and the subnet to deploy the VPC endpoint to. Repeat this step for all subnets in the table below, then click the Next button. Once all have been created, click *Next.

• After approximately 5 minutes, both endpoints should show “Status” active.

• On the Configure Policy Set section of the wizard, use the default ‘allow_all’ policy to allow all traffic from a Layer 4 perspective and click Finalize to push that default policy. In some versions of Fortigate CNF, the default “allow all” policy is automatically pushed and this step is unnecessary. In this case, click “Exit” to continue. You should then see the list of CNF instances again.

• To validate all GWLBe endpoints have been deployed and are active (takes ~5 mins), select and edit the CNF instance and click Next to view the GWLBe endpoints on the Configure Endpoints section of the wizard. Then click Exit to leave the CNF configuration wizard.

• Log into your AWS Account and navigate to the VPC Console > Endpoints. Each of the GWLBe endpoints you deployed in the FortiGate CNF Console should be visible in your account. Notice the tag name and value pairs assigned to the endpoints.

• This concludes this section.

Task 7: Modify VPC Route Tables to direct North-South Traffic to Fortigate CNF for inspection

• The initial deployed terraform template is a working deployment with ingress traffic NAT’d to all of the EIP’s by the IGW. Egress traffic is sent to the IGW by a default route in each route table pointing to the IGW. The initial deployment will not have any security, except for the security groups. This initial template design is depicted in this picture:

• The default VPC route tables route the traffic directed at one of the EIP’s into the VPC as local traffic. In other words, if the traffic is directed at an Elastic IP on the NLB or one associated with a Linux instance, the IGW will NAT the traffic to the private IP associated with the EIP public IP. For egress traffic, all VPC route tables have a default route that points to the IGW.

• Once we deploy a FortiGate CNF instance and the associated endpoints, we will need to modify the Spoke VPC route tables for the CNF instances to inspect the traffic. To redirect the ingress traffic, we need a few route table entries added to the IGW Ingress Route Table. To redirect egress traffic, change the default route in the private route table. The modified design will look like this:

• The tricky part here is to make sure you point the routes at the correct CNF Endpoint, i.e. the endpoint in the same AZ as the route table that you are modifying. If you don’t do this correctly, you will create routes that push the traffic across AZ’s and add cost to the deployment. Watch for the hints below to assist with this.

• Log into your AWS account and navigate to the Console Home.

• Click on the VPC icon

• First, we need to understand which CNF Endpoint is deployed in each AZ. To do this, click on “Endpoints” in the left pane.

• Then choose one of the CNF Endpoints and click subnets in the lower window.

• From this screen, you can see the subnet id where the Endpoint is deployed. You have a few options here.

  • You could navigate to the subnet tab on the left navigation pane and check which AZ that subnet is in using the subnet id.
  • You might notice that the IP address is 10.0.4.75. If you check the network diagram above, you can see that the 10.0.4.0/24 CIDR is in AZ2.
  • In this case, I included the AZ in the name of the name of the subnet “cnf-dist0-prod-app-az2” in the terraform that deployed the workshop VPC. It’s a useful hint in this case, but that may not be true in other VPC environments.
  • Nevertheless, this endpoint (vpce-xxxxc79b) is deployed in AZ2 and (vpce-xxxxc150) is deployed in AZ1.
  • You might want to add this info to your scratchpad.

• Now let’s modify the route tables. Click on “Route tables” in the left pane

• Highlight the IGW Ingress Route table named “cnf-dist-rec-igw-rt”.
• Click on the “Routes” tab at the bottom.
• Click on “Edit routes”.

• We could just change the full VPC CIDR Route and send the traffic to one of the GWLB Endpoints we created earlier. That would redirect all ingress traffic to one AZ or the other. But that would create cross AZ traffic and that would drive up the cost of the deployment. Don’t do this!

• Instead, let’s create an entry for each VPC subnet that we want to redirect and send it to the GWLBe in the same AZ. In this example, we have an NLB with a subnet mapping in the Public Subnet in each AZ. We can see this by looking at the Network Mapping associated with the NLB.

• So lets add an IGW Ingress Route Table entry for each Public Subnet CIDR and send that traffic to the GWLBe in the same AZ.
  • Remember, 10.0.0.0/24 is in AZ1 and the VPC Endpoint for AZ1 is vpce-xxxxc79b
  • 10.0.3.0/24 is in AZ2 and the VPC Endpoint for AZ2 is vpce-xxxxc150

• If we want the firewall to inspect traffic going to the EIP associated with the Linux instances, we need to add a similar route entry. The Linux instances are in the private subnet. Those CIDR’s are 10.0.2.0/24 and 10.0.5.0/24. So add route table entries for those CIDR’s.
• Click “Save changes”
• These changes redirect ingress traffic. Now lets redirect egress traffic.

• In this example, all the traffic goes to the linux instances and those instances are in the private subnets. The ingress traffic can be directed at the NLB subnet mappings or directly to the EIPs on the Linux instances. To have the egress traffic inspected, we need to redirect the traffic leaving the private subnet into the GWLBe.
• Navigate back to the “Route tables” screen.

• Currently, the private route tables are sending all traffic to the IGW. This will not allow Fortigate CNF to inspect egress traffic. In the private subnet table, add a default route to send all traffic leaving the private subnet to the GWLBe in the same AZ.
• Highlight the private route table for AZ1.
• Click the “Routes” tab at the bottom
• Click “Edit routes”

• Change the default route target to the GWLBe in AZ1.
• Click “Save changes”

• Navigate back to the “Route tables” screen and change the default route for the private subnet in AZ2.

• Highlight the route table for the private subnet in AZ2.
• Click “Routes” tab at the bottom
• Click “Edit routes”

• Change the default route target to the GWLBe in AZ2.
• Click “Save changes”

• Ingress and Egress traffic is now being sent to Fortigate CNF for inspection.

• The next task will create a “Policy Set” for Fortigate CNF and this will allow us to create a security policy and log the traffic.

• This concludes this section.

Deploying FortiGate CNF Discussion Points

Discussion Points During a Demo - Chapter 5

Key reasons for using a Next Generation Firewall in the cloud:

• FortiGate CNF delivers frictionless security at any scale for AWS environments. Fortinet manages the service delivery infrastructure, simplifying network security operations and lowering costs.
• FortiGate CNF combines next-generation firewall (NGFW) capabilities like intrusion prevention system (IPS), web filtering, domain name system (DNS) security, and more—with distinct cloud advantages.
• Zero Operations Overhead: Focus only on security-policy management and offload service-infrastructure maintenance to Fortinet
• Elastic Licensing: Pay only for what you use, when you use it
• Leverage Existing Infrastructure: Use existing Fortinet Fabric Ready Solutions like FortiManager, FortiAnalyzer for single pane of glass management and FortiGuard for threat intelligence.
• Use FortiGate CNF for Inbound, Outbound, and East-West Traffic Inspection and Protection
• Let Fortinet manage the complexities of high-resiliency and scalability of the service delivery infrastructure

Key questions during your demo

When giving this TEC Workshop as a demo, the following questions will provide a basis for next steps and future meetings:

• Do you have sufficient in-house expertise to manage the complexities of high-resiliency and scalability of the service delivery infrastructure? Fortinet manages the service delivery infrastructure, simplifying network security operations and lowering costs.
• Do you have dynamic cloud infrastructure that requires dynamic security policies? FortiGate CNF can be dynamically built and updated based on tags and other attributes that scales with a changing cloud infrastructure.
• Do you have a need for a single pane of glass for security policy management across multi-cloud and on-premises environments? Use existing Fortinet Fabric Ready Solutions like FortiManager, FortiAnalyzer for single pane of glass management and FortiGuard for threat intelligence.
• Do you require traffic inspection of Inbound, Outbound, and East-West Traffic Inspection and Protection? Yes, FortiGate CNF can be used for Inbound, Outbound, and East-West Traffic Inspection and Protection.
• Do you anticipate your network bandwidth needs to grow over time? By autoscaling the number of instances based on traffic load, FortiGate CNF can scale up to 20 Gbps of firewall throughput dynamically. It will also scale down when traffic load decreases resulting in cost savings over static environments.
• Where can I find a FAQ for FortiGate CNF? https://docs.fortinet.com/index.php/document/fortigate-cnf/latest/frequently-asked-questions/982783/frequently-asked-questions

Task 8: Create Policy Set for Fortigate CNF

• At this point, we are using the default allow_all policy set which allows all communication to be allowed without any restriction from a Layer 4 and Layer 7 perspective.

• To customize the actual L4 rules and L7 security profile groups applied, in the FortiGate CNF Console navigate to Policy & Objects > Policy Sets to create your own policy set. Simply click Create New, select Policy Set, and give your policy set a name.

• Before adding in L4 rules within the policy set, create a few simple address objects. Navigate to Policy & Objects > Addresses, click New, and Address. Then create each of the address objects below.

• Next, create an Address Group to include all the RFC 1918 class objects. On the same page, click New, and Address Group. Then create each the address object below.

• In FortiGate CNF you can create different types of address objects to be more flexible and granular in your rules within your policy set. Create an FQDN based address object by clicking New, and Address. Select FQDN for Type, then create the address object below.
• Create an address object by clicking New, and Address. Select IP Range for Type, then create the address object below using the output of “What’s My IP”. When can use this Address Object to filter out the probe’s that commonly come from the internet.

• Geography based address objects are available in FortiGate CNF. This allows controlling traffic based on public IPs assigned to countries around the globe. These objects can be used as a source or destination object within policies used in a policy set. Create a geo based address object by clicking New, and Address. Select Geography for Type, then create the address objects below.

• Dynamic metadata based address objects are available in FortiGate CNF. This allows controlling of traffic based on things such as VPC ID, Auto Scale Group, EKS Cluster or Pod, and even Tag Name + Value pairs for a given AWS account and region. Create a dynamic based address object by clicking New, and Address. Select Dynamic for Type, then create the address objects below.

Note: For each object, you will use the same values for these settings:

Here is the dynamic object to create:

• Now you will create a policy set to enforce L4 rules using the address objects you just created in the previous steps. Navigate to Policy & Objects > Policy Sets and click New, Policy Set. Give it a name and click Ok. You will be returned to the list of policy sets. Select your policy set and click Edit.

• Now you can create the policies listed below to control all directions of traffic within the example environment. Click New and create the policies listed below:

• In order to use this policy set, it must be applied to the deployed FortiGate CNF Instance. Navigate to CNF instances and select and edit the CNF Instance then click the Configure Policy Set bread crumb. In the Apply Policy Set, select your policy set then click Save then Finalize.

• Since we configured Fortigate CNF to use the Linux instance in AZ1 as an “External Syslog Server” and we allowed SSH into the “ApacheBackend” instances, lets SSH into the Linux Instance in AZ1 and look at the CNF logs.

• Open a terminal and SSH to the Public IP of the Linux instance in AZ1 using the keypair for the linux instance.

• Linux Instance Public IP

• SSH into the instance (standard terminal. If you use windows, you may use putty)

• Use “lnav /var/log/syslog” tool to view the syslog

• Use the arrow keys to navigate in the window (e.g. RIGHT ARROW). Read up on the lnav tool for more information.
• Use “G” key to go to the end of the logs

• Let’s exercise a few of the policies and filter the logs using lnav.
• First, let’s get another terminal window and ssh into the linux instance in AZ2. Grab the IP from your scratchpad.

• Verify the log entry using lnav.
• Below is the log entry using the Dynamic Address Object “ApacheBackend” that allows SSH into linux instances.

• While we are here, let’s ping ipinfo.io and test the ipinfo_rule in the policy set.
• FortiGate CNF used the FQDN address object “ipinfo.io” to resolve the IP address and apply the security policy.

• Let’s try the “BlockList-Outbound” policy and ping an IP address in Russia. Try ping 109.169.203.90.

• Feel free to experiment with Fortigate CNF and watch the log to verify correct policy enforcement.

• This concludes this section.

Deploying FortiGate CNF Policy Sets

Discussion Points During a Demo - Chapter 6

Key reasons for using a Next Generation Firewall in the cloud:

• FortiGate CNF delivers frictionless security at any scale for AWS environments. Fortinet manages the service delivery infrastructure, simplifying network security operations and lowering costs.
• FortiGate CNF combines next-generation firewall (NGFW) capabilities like intrusion prevention system (IPS), web filtering, domain name system (DNS) security, and more—with distinct cloud advantages.
• Zero Operations Overhead: Focus only on security-policy management and offload service-infrastructure maintenance to Fortinet
• Elastic Licensing: Pay only for what you use, when you use it
• Leverage Existing Infrastructure: Use existing Fortinet Fabric Ready Solutions like FortiManager, FortiAnalyzer for single pane of glass management and FortiGuard for threat intelligence.
• Use FortiGate CNF for Inbound, Outbound, and East-West Traffic Inspection and Protection
• Let Fortinet manage the complexities of high-resiliency and scalability of the service delivery infrastructure

Key questions during your demo

When giving this TEC Workshop as a demo, the following questions will provide a basis for next steps and future meetings:

Task 9: Cleanup

• When finished experimenting with the First VPC, let’s cleanup the CNF Endpoints, the CNF Instance, and the Workload-VPC. Start by removing all routes in the Workload VPC that point to the CNF endpoints.
• Log into your AWS account and navigate to the Console Home.
• Click on the VPC icon

• Click on “Route tables” in the left pane

• Highlight the IGW Ingress Route table named “cnf-dist-rec-igw-rt”.
• Click on the “Routes” tab at the bottom.
• Click on “Edit routes”.

• Remove the four routes that have a “Target” that points to a “vpce”

• Click “Save Changes”

• Highlight the private route table for AZ1.

• Click the “Routes” tab at the bottom

• Click “Edit routes”

• Change the default route target to the IGW in the VPC.
• Click “Save changes”

• Navigate back to the “Route tables” screen and change the default route for the private subnet in AZ2.
• Click the “Routes” tab at the bottom
• Click “Edit routes”
• Change the default route target to the IGW in the VPC.
• Click “Save changes”

• Cleanup the Fortigate CNF endpoints and instance ** Navigate back to https://fortigatecnf.com ** Click on CNF Instances ** Double-click the CNF instance we created

** Advance the menu to “Configure Endpoints” ** Highlight each endpoint and click “Delete”

** Click “Refresh” periodically and wait for both endpoint to disappear (~5 min). ** Advance the menu tab to Configure Endpoints

** Click on “CNF Instances” ** Highlight the CNF Instance ** Click “Delete” ** Wait approximately 10 minutes for the CNF instance to finish deleting

• Log into your AWS account and navigate to the Console Home.
• Click on the “AWS Cloudshell” icon
• cd tec-recipe-distributed-ingress-nlb/
• terraform destroy –auto-approve

• Wait for “destroy complete”

• This concludes this section.

Task 10: Create Centralized Egress Workload VPC using Terraform in AWS Cloudshell

• Log into your AWS account and navigate to the Console Home.

• Click on the AWS CloudShell icon on the console navigation bar

• Clone a repository that uses terraform to create a distributed ingress workload vpc

  git clone https://github.com/FortinetCloudCSE/FortiGate-AWS-CNF-TEC-Workshop.git

• Change directory into the newly created repository for distributed_ingress_nlb

  cd ~/FortiGate-AWS-CNF-TEC-Workshop/terraform/centralized_ingress_egress_east_west/

• Copy the terraform.tfvars.example to terraform.tfvars

  cp terraform.tfvars.example terraform.tfvars

• Edit the terraform.tfvars file and insert the name of a valid keypair in the keypair variable name and save the file

• Use the “terraform init” command to initialize the template and download the providers

  terraform init

• Use “terraform apply –auto-approve” command to build the vpc. This command takes about 5 minutes to complete.

terraform apply --auto-approve

• When the command completes, verify “Apply Complete” and valid output statements.
  • Copy the “Outputs” section to a scratchpad. We will use this info throughout this workshop.

The network diagram for the centralized egress vpc looks like this:

• This concludes this section.

Task 11: Initialize FortiAnalyzer

• In the next couple of tasks, we will initialize FortiManager and FortiAnalyzer. Let’s start with the FortiAnalzyer. Find the FortiAnalyzer IP address and instance ID from the output of the Terraform template you saved to your scratchpad. Be sure to accept the self-signed certificate presented by FortiAnalyzer.

• Login to FortiAnalyzer with the credentials you used to create your FortiCloud account.
• Click Free Trial
• Click Login with FortiCloud

• Scroll to the bottom of the “Terms” and click the box that Accepts the terms of the license.
• Click Accept

• This will cause the FortiAnalyzer to reboot and apply the license. This will take a minute.

• Once the FortiAnalyzer has rebooted, accept the self-signed certificate and login again with with the default credentials of admin and instance-id as password.

• Accept the defaults on the Setup screen and click Begin

• Accept the default hostname, unless you want to change it.

• Now change the default password (instance-id) to something more secure. This will log you out and force you to login again with the new password.

• Setup complete, click Finish

• This concludes this section.

Task 12: Initialize FortiManager

• In this task, we will initialize FortiManager. Find the FortiManager IP address and instance ID from the output of the Terraform template you saved to your scratchpad. Be sure to accept the self-signed certificate presented by FortiManager during initial login.

• Login to FortiManager with the credentials you used to create your FortiCloud account.
• Click Free Trial
• Click Login with FortiCloud

• Scroll to the bottom of the “Terms” and click the box that Accepts the terms of the license.
• Click Accept

• This will cause the FortiManager to reboot and apply the license. This will take a minute.

• Once the FortiManager has rebooted, accept the self-signed certificate and login again with the default credentials of admin and instance-id as password.

• Accept the defaults on the Setup screen and click Begin

• Accept the default hostname, unless you want to change it.
• Click Next

• Now change the default password (instance-id) to something more secure. This will log you out and force you to login again with the new password.

• This concludes this section.

Task 13: Deploy FortiGate CNF and Gateway Load Balancer Endpoints

The network diagram for the centralized egress vpc (included here for convenience) looks like this:

• Prerequisite: You must have completed “Task 4: Subscribe to FortiGate CNF in AWS Marketplace” before continuing. This task will only need to be completed once per AWS account.

• Prerequisite: You must have completed ““Task 5: Onboard an AWS account to FortiGate CNF” before continuing. This task will only need to be completed once per AWS account.

• In the FortiGate CNF console, navigate to CNF instances and click New.

• Provide a name for the CNF instance. This workshop example uses corp-us-west-2-cnf.

• Select us-west-2 for the region.

• Click FortiManager mode

• Under Logging Options, make sure Internal S3 Logging is unchecked

• select FortiAnalyzer for the external logging and insert the FortiAnalyzer IP from your scratchpad.

• Under Endpoints, click New to create a GWLB Endpoint for AZ1

• 

• Provide a Name for the endpoint this workshop uses corp-us-west-2-endp-az1

• Use the dropdown to select the account you onboarded in Task 5

• Choose the tec-cnf-lab-inspection-vpc from the dropdown for VPC ID

• Uncheck Select from all subnets and choose cnf-dist-rec-app-fwaas-az1 from the dropdown

• Click OK to continue

• Under Endpoints, click New to create a GWLB Endpoint for AZ1

• Provide a Name for the second endpoint. This workshop uses corp-us-west-2-endp-az2

• Use the dropdown to select the account you onboarded in Task 5

• Choose the tec-cnf-lab-inspection-vpc from the dropdown for VPC ID

• Uncheck Select from all subnets and choose cnf-dist-rec-app-fwaas-az2 from the dropdown

• Click OK to continue

• The “Create CNF” screen should look like this
• Click OK to continue

• The CNF Instance should show up as active after roughly 10 minutes (Now is a great time for a break :) ). Then you can select and edit it to deploy endpoints and assign a policy set.

• Approximately 10 minutes later…

• To validate all GWLBe endpoints have been deployed and are active, select and edit the CNF instance and click Edit.

• To view the GWLBe endpoints on the Configure Endpoints section of the wizard. Verify that both endpoints are active and have a status of Active.

• Click Troubleshooting. Here you can see that FortiManager status is currently disabled. We will connect the FortiManager in a later task. You can also see that allow_all policy is currently active.
• Click Finalize to continue

• This concludes this section.

Task 14: Modify VPC Route Tables to direct egress traffic to Fortigate CNF for inspection

• The initial deployed terraform template deploys an inspection VPC with a FortiManager and FortiAnalyzer and a couple of customer or workload VPC’s connected to a Transit Gateway (TGW). This design allows outbound traffic to egress through the NAT Gateways and the option to add various types of AWS load balancers for ingress traffic. The interesting aspect of this design pattern allows many VPC’s to share a single FortiGate CNF instance. This design pattern is depicted in this picture:

• The default VPC route tables route the egress traffic to the NAT Gateways and the ingress traffic is directed to the TGW for each Spoke VPC. Traffic that is going to the FortiAnalzyer, FortiManager and Jump Box are routed locally to the EIP associated with each device. This design is a working design, but does not give the FortiGate CNF instance the opportunity to inspect the traffic. We need to change the VPC route tables to force egress and ingress traffic through the GWLB Endpoints we created in the previous task. This give the FortiGate CNF instance the opportunity to inspect ingress and egress traffic. The modified design will look like this:

Note: Changes to the route tables are in RED.

• The first change will be to the public route table in the inspection VPC in AZ1.
• Log into your AWS account and navigate to the Console Home.

• First, we need to understand which CNF Endpoint is deployed in each AZ. To do this, click on “Endpoints” in the left pane.

• Then choose one of the CNF Endpoints and click subnets in the lower window.

• From this screen, you can see the subnet id where the Endpoint is deployed. You have a few options here.

  • You could navigate to the subnet tab on the left navigation pane and check which AZ that subnet is in using the subnet id.
  • You might notice that the IP address is 10.0.1.54. If you check the network diagram above, you can see that the 10.0.1.0/24 CIDR is in AZ1.
  • In this case, I included the AZ in the name of the name of the subnet “tec-cnf-lab-inspection-fwaas-az1-subnet” in the terraform that deployed the workshop VPC. It’s a useful hint in this case, but that may not be true in other VPC environments.
  • Nevertheless, this endpoint (vpce-xxxx0c92) is deployed in AZ1 and (vpce-xxxxdd75) is deployed in AZ2.
  • You might want to add this info to your scratchpad.

• Now let’s modify the route tables. Click on “Route tables” in the left pane

• Highlight the Inspection VPC Public Route table named “tec-cnf-lab-inspection-public-rt-az1”.
• Click on the “Routes” tab at the bottom.
• Click on “Edit routes”.

• Click Edit Routes

• Modify the target for the East-West Supernet CIDR to point to the GWLB Endpoint in AZ1. This will redirect ingress traffic to the GWLB Endpoint for inspection.
• Click Save changes

• Now do the same for the Inspection VPC Public Route table in AZ2. Click Route Tables

• Highlight the Inspection VPC Public Route table named “tec-cnf-lab-inspection-public-rt-az2”.
• Click on the “Routes” tab at the bottom.

• Click on “Edit routes”.

• 

• Modify the target for the East-West Supernet CIDR to point to the GWLB Endpoint in AZ2.

• Click Save changes

• Now let’s redirect egress traffic coming from the TGW to the GWLB Endpoint for inspection. Click Route Tables

• Highlight the Inspection VPC Public Route table named “tec-cnf-lab-inspection-private-rt-az1”.
• Click on the “Routes” tab at the bottom.

• Click on “Edit routes”.

• 

• Modify the target for the default route (0.0.0.0/0) to point to the GWLB Endpoint in AZ1.

• Click Save changes

• Now let’s do the same for the egress traffic in AZ2. Click Route Tables

• Highlight the Inspection VPC Public Route table named “tec-cnf-lab-inspection-private-rt-az2”.
• Click on the “Routes” tab at the bottom.

• Click on “Edit routes”.

• 

• Modify the target for the default route (0.0.0.0/0) to point to the GWLB Endpoint in AZ2.

• Click Save changes

• The next task will register the FortiGate CNF instance on FortiManager so we can create a security policy and push policy.

• This concludes this section.

IaC Discussion Points

The Centralized Egress VPC is commonly used when there is a strong desire to control egress traffic through a common set of NAT Gateways contained within an common inspection VPC. The benefits of this design is that you control the egress point of all connected Spoke VPC’s through a central VPC with a single set of NAT Gateways. There must be a single NAT Gateway per Availability Zone within the inspection VPC, which have an hourly cost. The spoke VPC’s are connected to the inspection VPC via a Transit Gateway. The Transit Gateway is a regional resource and has a monthly cost.

Discussion Points During a Demo - Chapter 8

The same discussion points apply to this chapter as in Chapter 3. These discussion points are repeated here for convenience.

Fortinet provides a large library of infrastructure as code (IaC) templates to deploy baseline and iterate POC and production environments in public cloud. IaC support includes Terraform, Ansible, and cloud-specific services such as Azure ARM, AWS Cloudformation, and Google Deployment templates. Terraform Providers are available for several Fortinet products to insert and iterate running configuration.

For more information, review the following:

• FortiOS 7.2 Admin Guide

• Terraform Providers

• Ansible Modules

Advantages of Using AWS CloudShell for Deployment

AWS CloudShell is a browser-based shell that makes it easy to securely manage, explore, and interact with your AWS resources. CloudShell is pre-authenticated with your console credentials, and common development and operations tools are pre-installed. CloudShell is available in all commercial AWS regions at no additional cost and provides an environment with preconfigured CLI tools and access to AWS services. CloudShell provides a temporary 1 GB storage volume that is deleted after 120 minutes of inactivity. CloudShell is a convenient method to deploy IaC templates for demonstrations and quick deployments.

Alternative Methods of using Terraform in Production Environments

AWS Cloudshell is a nice environment for deploying demo environments. However, for production environments, it is recommended to use a local workstation or a CI/CD pipeline. If your customer is asking about how to deploy Terraform in production, you can point them to the following resources:

• https://aws.amazon.com/blogs/apn/terraform-beyond-the-basics-with-aws/

Be sure to point out that the Fortinet Terraform templates are free to use and modify. These templates are designed to illustrate reference architectures in a demo environment only and may require modification to meet production requirements.

Key questions during your demo

When giving this TEC Workshop as a demo, the following questions will provide a basis for next steps and future meetings:

• Has your organization standardized on an IaC tool-set for infrastructure provisioning and iteration?
• How are the responsibilities for infrastructure assigned? Does cloud network fall under a DevOps, Cloud Networking, or Application Delivery team, as examples?
• What is organizations view on how IaC can improve workflows?
• Is workflow automation in cloud and cross-organizational collaboration important within your cloud business?

Task 15: Register FortiGate CNF instance with FortiManager

• In this task, we will register the FortiGate CNF instance with FortiManager. This will allow us to create and push a security policy to the FortiGate CNF instance.
• Login to the FortiGate CNF console FortiGate CNF Home with your FortiCloud credentials.

• Click on the proper Account Selection choice

• 

• Click on CNF Instances in the left pane

• Double-click on the FortiGate CNF instance to open the instance details (or highlight the instance and click Edit).

• Click on Display Primary Fortigate Information button

• Copy the FortiGate CNF Information into your scratchpad

• 

• Open a new browser window and login to the FortiManager IP in your scratchpad

• 

• Click on Device Manager

• Click on Add Device

• Click on Discover Device in the “Add Device” wizard

• Use the FortiGate CNF Information in your scratchpad to fill in the IP Address of the FortiGate CNF instance
• Click Use Legacy Device Login button
• Enter the Username and Password for the FortiGate CNF instance
• Click Next to continue

• In a production environment, you might want to add a Description, Provisioning Template, Folder and Device Group. For this lab, we will just add a Description.
• Click Next to continue

• Wait for the “Device Discovery” process to complete (approximately 1 minute)
• Click Import Now to continue

• Click Import Policy Package
• (We are not using “Import AP Profiles or FortiSwitch Templates” in this lab)
• Click Next to continue (We are not using “Import AP Profiles or FortiSwitch Templates” in this lab)

• Confirm FG-traffic is highlighted
• Click Import each VDOM step by step
• Click Next to continue

• Click Import All for Policy Selection
• Click Import all objects for Object Selection
• Uncheck “Add mappings for all unused interfaces”
• Click Next to continue

• Click “Use Value From” FortiGate for any objects that have conflicts
• Click Next to continue

• Expand the conflicts dropdowns if you like
• Click Next to continue

• Verify the “Import Summary” and click Next VDOM to continue

• We will not be importing the root VDOM.
• Click Cancel to continue

• Verify the “FG-Traffic” VDOM is imported

• Click on Main Menu (upper left corner)
• Click on Policy & Objects
• Verify the FortiGate CNF instance has a firewall policy (this should be the default “allow all” policy)

*

• The next task will register the FortiGate CNF instance on the FortiAnalyzer to allow logging.

• This concludes this section.

Task 16: Register FortiGate CNF instance with FortiAnalyzer

• In this task, we will register the FortiGate CNF instance with FortiAnalyzer. This will allow FortiGate CNF to send logs to the FortiAnalyzer.
• Find the FortiAnalyzer IP Address in your scratchpad.
• Open a new browser window and login to the FortiAnalyzer IP using the credentials you created in Task 11.

• Check the FortiGateCNF instance in the list of devices. If it is not there, wait a few minutes and refresh the browser window.
• Click on Authorize

• Highlight the FortiGateCNF instance and authorize the device into the root adom. A production environment might use a different ADOM, but root is sufficient for this workshop.
• Click OK to continue

• Verify successful authorization. Click Close to Continue

• The next task will create a security policy and push it to the FortiGate CNF instance.

• This concludes this section.