This recipe introduces the process of deploying FortiGate for AWS. See below for recipes in this process:

1. Determine your licensing model
2. Register and download your licenses
3. Create a VPC and subnets
4. Attach the new VPC to the Internet gateway
5. Subscribe to the FortiGate
6. Create a routing table and associate subnets
7. Connect to the FortiGate
8. [Use case] Set up a Windows Server in the protected network
9. [Connectivity test] Configure FortiGate firewall policies and virtual IPs

The FortiGate Enterprise Firewall for Amazon Web Services (AWS) is deployed as a virtual appliance in AWS (IaaS). This recipe shows you how to install and configure a single instance FortiGate-VM virtual appliance in AWS to provide a full NGFW/UTM security solution to protect your workloads in the AWS IaaS.

Networking is a core component in using AWS services, and using virtual private clouds (VPCs), subnets, and virtual gateways help you to secure your resources at the networking level.

This recipe covers the deployment of simple web servers, but this type of deployment can be used for any type of public resource protection, with only slight modifications. With this architecture as a starting point, you can implement more advanced solutions, including multi-tiered solutions.

In this recipe, two subnets are created: Subnet1, which is used to connect the FortiGate-VM to the AWS Virtual Gateway on the public-facing side, and Subnet2, which is used to connect the FortiGate-VM and the Windows server on the private side.

The post Deploying FortiGate for AWS appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate for AWS. See below for the rest of the recipes in this process:

1. Determine your licensing model
2. Register and download your licenses
3. Create a VPC and subnets
4. Attach the new VPC to the Internet gateway
5. Subscribe to the FortiGate
6. Create a routing table and associate subnets
7. Connect to the FortiGate
8. [Use case] Set up a Windows Server in the protected network
9. [Connectivity test] Configure FortiGate firewall policies and virtual IPs

This section shows you how to connect the new VPC to the Internet gateway. Note that if you’re using the default VPC, the Internet gateway should already exist.

1. In the Virtual Private Cloud menu, select Internet Gateways, then select Create Internet Gateway.
2. In the Name tag field, set a name for the Internet gateway, then select Yes, Create.

3. Select the Internet gateway, then select Attach to VPC.

4. Select the VPC that you created and select Yes, Attach. The state of the Internet gateway will change from detached to attached.

The post Attach the new VPC to the Internet gateway appeared first on Fortinet Cookbook.

This cookbook recipe shows how grouping multiple interfaces into a zone can simplify firewall policies. In this example, we create VLAN10, VLAN20, and VLAN30 and add them into a zone called the “LAN Zone.” Instead of having to reference all 3 interfaces separately as a source interface in our firewall policy, we can just use the single zone object.

Zones can also group many other kinds of interfaces in addition to VLANs, such as physical ports or IPsec tunnels.

1. Creating the VLAN interfaces
Go to Network > Interfaces and select Create New > Interface. Create the VLAN interface for VLAN ID 10 and enable the DHCP server option.
Create the VLAN interface for VLAN ID 20 and enable the DHCP server option.
Create the VLAN interface for VLAN ID 30 and enable the DHCP server option.
2. Creating the zone
Under Network > Interfaces, select Create New > Zone, name the zone LAN Zone, and add the newly created VLANs to the zone. Leave Block intra-zone traffic enabled to prevent communication between the VLAN interfaces.
3. Creating a firewall policy for the zone
Navigate to Policy & Objects > IPv4 Policy and create a firewall policy allowing any VLAN in the “LAN Zone” permission to access the Internet. Select any security profiles desired with best practices and business requirements in mind.
Results
Users from VLAN10, VLAN20, or VLAN30 will now have Internet access.
As new VLANs are added in the future, they can be added to “LAN Zone” without having to modify the firewall policy we created in Step 3.

For further reading, check out Zones in the FortiOS 5.6 Handbook.

The post Using zones to simplify firewall policies appeared first on Fortinet Cookbook.

This recipe guides you through the process of configuring and testing emails for your protected domain. 

Configuring Incoming Email Relaying
First we’ll need to configure the email destination of the FortiMail cloud unit. Go to Domain & User > Domain > Domain. Select a domain and then select Edit. Select Host from the Relay type dropdown menu if you know the IPs or the hostnames of your receiving server  Enter the SMTP server and Fallback server. Select OK. Note: When the FML cloud unit is provisioned, the incoming email relaying configuration is set up according to information provided in the section “Receiving Mail Servers Addresses” and “Protected Domain Names” of the provisioning file.
Testing Incoming Emails Without Changing Public MX Records
Next we’ll test the FML cloud units ability to deliver incoming emails to a test a user without changing your public MX record. This process is optional. If you plan on changing your public MX, skip to the next section. A Linux PC with shell available is required. Send a test email to your domain with these commands: Note: Lines beginning “–>>” are shell commands. Do not enter “–>>”. Assume your assigned FML cloud unit’s host name is gwxxx.fortimail.com Note: The test user you use should exist on the server. The email address in the “mail from” and “rcpt to” commands must be surrounded by angle brackets “<…>”. -->>telnet gwxxx.fortimail.com 25 220 gwxxx.fortimail.com ESMTP Smtpd; [Date and Time] -->>ehlo 250-gwxxx.fortimail.com Hello linuxhost.example.com [public ip of linuxhost.example.com], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 10485760 250-DSN 250-STARTTLS 250-DELIVERBY 250 HELP -->>mail from: <testuser@example.com> 250 2.1.0 <testuser@example.com>... Sender ok -->>rcpt to: <testuser@example.com> 250 2.1.5 <testuser@example.com>... Recipient ok -->>data 354 Enter mail, end with "." on a line by itself -->>Subject: Test -->>Test -->>. -->>quit 250 2.0.0 u0XXXXXX000000-u0XXXXXX000000 Message accepted for delivery 221 2.0.0 gwxxx.fortimail.com closing connection Connection closed by foreign host Check the mailbox of the user “testuser@example.com” to see if they received the email. If you did not receive the email, refer to the FML log to see the reason and modify your configuration or tests accordingly. The problem may likely be due to the improper configuration of the relaying email server.
Testing Incoming Emails After Changing your Public MX
Now we’ll need to change your public MX record to the hostname of the FML cloud unit and test incoming emails. Incoming emails to your domain from internet are delivered to the host of the public MX record for your domain.  Assuming your current public MX record is “example.com. 86400 IN MX 10 mail.example.com” change it to “example.come 86400 IN MX 10.gwxxx.fortimail.com” Test incoming emails using whatever email client software you desire. It is important you use an email client software so your PC can correctly resolve the public MX record of your domain. Check the mailbox of the user “testuser@example.com” to confirm the testing was successful. If you cannot receive the email, refer to the FML log to see the reason and modify your configuration accordingly. It is possible it could be because the relaying email server is not configured correctly, in which case you would need to reattempt the initial Configure Incoming Email Relaying section.

The post Cloud Unit Configuration in FortiMail appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. Once validation is successful, click OK. You can also download the ARM template package used during the configuration process.
2. On step 5, Buy, click Create.
3. FortiGate and all associated resources are now being created. The screen returns to the dashboard. Wait ten to fifteen minutes to complete deployment.

The post Create FortiGate instances appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

This is the most crucial configuration to ensure the HA setup functions.

1. Locate the Azure load balancer, then click Load balancing rules.
   
2. Click Add to create a new load balancing rule. Configure like the following:
   
   1. Name: unique load balancing rule name
   2. Frontend IP address: choose from the two available values. In this example, let’s choose the one associated with FortiGate A.
   3. Protocol: TCP
   4. Port: 3389 for an RDP request made by your remote desktop application.
   5. Backend port: 3389 for RDP port listening on the Windows Server.
   6. Backend pool: by default, there is only one value consisting of the two FortiGate instances.
   7. Health probe: keep as-is.
   8. Session persistence: to learn about this option, click the information symbol. For testing purposes, select None.
   9. Do not change any other field. Click OK.
3. From the PC, start the remote desktop client by specifying FortiGate A’s public IP address. If you can see the Windows desktop, this means FortiGate A’s firewall policy for RDP port forwarding is working as expected. At this stage, you know that at least FortiGate A’s port forwarding works as expected.
   
4. Test the failover case by shutting down FortiGate A. It may take a few minutes to completely shut down.
   
5. When one FortiGate is shut down, the Azure HA set shows the status as the following:
6. If only FortiGate B is found to be alive, the Azure load balancer passes incoming traffic only to FortiGate B. Verify your management GUI access to FortiGate A does not work after shutdown.
   
7. From your PC, start the remote desktop client by specifying the public IP address previously assigned to FortiGate A. This IP address is what you specified in the load balancing rule as the frontend IP address. You should still be able to access the Windows Server through FortiGate B. Do not forget to make the same port forwarding configuration on FortiGate B as in the previous steps.
   

The post [Failover test] Create load balancing rules and access the Windows Server via remote desktop appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. Now let’s connect to FortiGate node A and node B. First, you must find the assigned public IP addresses. Navigate to the resource group you just created.
2. Select the virtual machine named <resource group name>-A. In this example, it is fortigateha001-A.FortiGate A’s public IP address can be found in its VM’s overview.
   You can also see this IP address as the load balancer’s public IP address “A”. In this example, the load balancer’s resource name is FortiGate-LB-PublicIP-A.
3. Le’ts also check the existing inbound NAT configuration on the load balancer. Locate <resource_name>publicLB. In this example, it is fortigate001publicLB. Click Inbound NAT rules. There are four rules: FortiGate-A 443, FortiGate-A 22, FortiGate-B 443, and FortiGate-B 22. We will use 443.
4. In your browser, navigate to https://<FortiGateA_IP_Address>. The login screen should appear. Enter the administrator username and password specified in Configure FortiGate initial parameters.
3. If you’re using a BYOL license, upload your license (.lic) file to activate the FortiGate. The FortiGate will automatically restart. After it restarts, log in again.
4. You should now be able to log in and see FortiGate-A’s dashboard as follows. In this example, the hostname is fortigate001-A. You can distinguish that this is FortiGate-A by the hostname. Note the look and feel may differ depending on the FortiOS version in use.
   
5. Log into the FortiOS management GUI, and navigate to Network > Interfaces. Verify the private IP addresses for port1 and port2 are properly assigned.
6. Now let’s access FortiGate B. You can find the public IP address in the load balancer’s public IP address “B”. In this example, the load balancer’s resource name is FortiGate-LB-PublicIP-B.
7. In your browser, navigate to https://<FortiGateA_IP_Address>. The login screen should appear. Enter the administrator username and password specified in Configure FortiGate initial parameters. By default, these attributes are the same as those of FortiGate A.
3. If you’re using a BYOL license, upload your license (.lic) file to activate the FortiGate. The FortiGate will automatically restart. After it restarts, log in again.
4. You should now be able to log in and see FortiGate B’s dashboard as follows. In this example, the hostname is fortigate001-B. You can distinguish that this is FortiGate B by the hostname. Fortinet highly encourages that FortiGate A and FortiGate B run the same FortiOS version.
   
   When using the Azure availability set, the two FortiGate instances’ firewall policy configurations are not automatically synchronized. You must manually force the same policy configuration on both nodes at all times.

The post Connect to the FortiGate appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. Set the initial parameters as follows:
   • FortiGate set name prefix: FortiGate name, set to distinguish from other resources.
   • FortiGate administrative username: specify FortiGate main administrator username. “admin” is not allowed as a username due to Azure restrictions.
   • FortiGate password: specify the administrator password.
   • Subscription: choose your subscription. This should differ from the screenshot below.
   • Resource group: specify the resource group name where FortiGate and associated resources will be accommodated.
   • Location: select the region where resources are hosted.

2. Click OK.

The post Configure FortiGate initial parameters appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. The following screen allows you to choose basic configuration for your FortiGate HA instance.Under PAYG/BYOL License, select the licensing model. FortiGate for Azure supports both on-demand (PAYG) and bring-your-own-license (BYOL) licensing models. PAYG is an Azure-embedded, hourly subscription model. BYOL is conventional annual perpetual licensing. To activate its functionality, you must obtain a license from Fortinet resellers or distributors and install the license from the FortiOS GUI. To register on Fortinet Support with a BYOL license, see step 4.
2. For PAYG, FortiGate hourly pricing depends on the instance type. Visit the Azure marketplace product page and click Plans, beside Overview.Note HA requires two FortiGate instances, so you will pay twice the prices shown.
   Note the prices do not include Azure instance compute fees.
3. Once FortiGate is deployed, PAYG users don’t need to register a license from the FortiOS GUI. To activate technical support, create the FortiGate instances, then contact Fortinet customer support (http://www.fortinet.com/support/contact_support.html) with the following information:
   • Your FortiGate VM instance’s serial number
   • Your Fortinet account’s email ID. If you don’t have a Fortinet account, you can create one at https://support.fortinet.com/login/CreateAccount.aspx
4. Licenses for the BYOL licensing model can be obtained through any Fortinet partner. After you purchase a license or obtain an evaluation license (60-day term), you will receive a PDF with an activation code. To register on Fortinet Support with a BYOL license, do the following. 
   1. Go to https://support.fortinet.com/ and create a new account or log in with an existing account.
   2. Go to Asset > Register/Renew to start the registration process. In the Specify Registration Code field, enter your license activation code and select Next to continue registering the product. Enter your details in the other fields.

   3. At the end of the registration process, download the license (.lic) file to your computer. You will upload this license later (in Connect to the FortiGate) to activate the FortiGates.

      After registering a license, Fortinet servers may take up to 30 minutes to fully recognize the new license. When you upload the license (.lic) file to activate the FortiGate, if you get an error that the license is invalid, wait 30 minutes and try again.

The post Determine your licensing model appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

This recipe details two ways to find the FortiGate HA product listing on Azure:

1. Log into the Azure portal, navigate the marketplace, then select FortiGate HA.
2. Go to the Azure marketplace product page.

1. Log into the Azure portal

1. Log into the Azure management portal, then click New > More services. Enter marketplace. Click Marketplace, then search for fortigate HA.
   

2. Choose the product name, then click Create.

2. Go to the Azure marketplace product page

1. Navigate to the marketplace product page.
   
2. Click GET IT NOW. In the popup, click Continue. It leads you to log into the Azure management portal. After logging in, the product description displays. Click Create.

The post Locate FortiGate HA for Azure in the Azure portal or Azure marketplace appeared first on Fortinet Cookbook.

This recipe introduces the process of deploying FortiGate High Availability (HA) Active Active for Microsoft Azure using Azure load balancer. See below for recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

FortiGate for Microsoft Azure is deployed as HA instances in Azure (IaaS). FortiGate is designed to provide a full NGFW/UTM security solution to protect your workloads in the Azure IaaS.

This process shows you how to install and configure two FortiGate nodes forming an Azure HA set in Azure, using an Azure load balancer to achieve Active-Active incoming traffic.

The post Deploying FortiGate Active-Active HA for Microsoft Azure appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

This recipe covers basic concepts relating to deploying FortiGate for Azure and contains the following subsections:

• • Traffic flow
  • Azure load balancer
    • Inbound NAT rules
    • Load balancing rules

Networking is a core component in using Azure services, and using a virtual network (VNet) and subnets with appropriate routing will help secure your resources at the networking level. Most required resources in HA are automatically deployed with ARM deployment templates embedded in the backend deployment process. Therefore you do not need to manually instantiate resources one by one or concern yourself with ARM templates.

An exception is when configuring load balancing rules on the automatically created Azure load balancer to be Active-Active for incoming traffic, as seen below. Two FortiGate instances are also deployed as part of an Azure HA set. This is the most basic architecture in this HA style. In this process, we will use RDP to make access to the Windows server fault-tolerant.

For further fault tolerance, you can create another Azure load balancer to be Active-Active for outgoing traffic, as seen below. This recipe does not cover this scenario.

In either case, there are typically at least two networks where a pair of FortiGate instances (FortiGate A and FortiGate B) as firewalls sit inline: subnet 1, named “PublicFacingSubnet” by default, which is used to connect the FortiGates’ port 1 to the public-facing side; and subnet 2, named “FortigateProtectedSubnet” by default, which is an internal protected network that connects to the FortiGates’ port 2.

A Windows Server is deployed on subnet 2, which is what you will create after subnet 1 and subnet 2 in order to test connectivity of incoming RDP access.

Traffic flow

Inbound traffic comes through the load balancer. The load balancer determines the traffic flow, unless a connection is already established, in which case the flow follows the existing path. For inbound traffic coming from the load balancer, both FortiGates become Active/Active once you configure load balancing rules on Azure.

For outbound traffic to be Active/Active, there must be another load balancer within the VNet which has user-defined routes (UDR) with next hops.

Generally, Active/Active using Azure load balancers for inbound and outbound traffic provides better availability in Azure. Fortinet does not recommend an Active/Passive solution. Any manipulation of UDRs or public IP addresses for Active/Passive solutions take 30 seconds to be applied after failover is initiated, whereas Azure load balancers can send probes as often as every five seconds and will stop forwarding traffic after two failures. With Azure load balancers, a failure is detected and mitigated with six to ten seconds.

The first time you access a FortiGate instance for initial configuration, inbound NAT is configured by default on the Azure load balancer for TCP ports 443 and 22 (443 = management GUI, 22 = SSH). For load balancing purposes, you need only one public IP address as the front end IP address, but there are two public IP addresses assigned to enable you to access both FortiGates at the same time.

Azure load balancer

All traffic from outside Azure passes through the load balancer first. The load balancer uses network address translation and port address translation (NAT/PAT) to connect a single public IP address  to the Azure VNet. The Azure portal has two options for configuring these NAT rules: inbound NAT rules and load balancing rules.

Inbound NAT rules

These rules are applied to a specific host and are not load-balanced. As such, these are typically used for management. The ARM template automatically configures ports 443 and 22 for management access to the GUI and SSH of FortiGate. Note these should not be confused with FortiGate’s port forwarding because their functionality is the same. The location is different; in this HA, FotiGates are located behind the Azure load balancer.

Load balancing rules

These rules also use PAT, but rather than being directed at a specific host, they are directed at a collection of VMs called a backend pool. In this case, the pool consists of FortiGate A and FortiGate B. These rules are necessary to provide HA and load balancing for any given service, and you need to create rules to achieve HA. See [Failover test] Create load balancing rules and access the Windows Server via remote desktop. In this example, you will test the fault-tolerance using RDP.

The post Basic concepts appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. In the third step, FortiGate IP address assignment, you will configure a static public IP address for FortiGate node A and for node B. If you click First public IP address resource name, you will see a preconfigured name, with Dynamic selected. Leave these as shown, as there is no need to click Create New unless you want to change the name.
   To access FortiGate’s management GUI console or to connect by SSH, you need public addresses assigned to FortiGate node A and node B. Static IP addresses are more convenient, as they are configured by default. Usually the default configuration is fine without modification.
2. After confirmation, click OK.
3. Repeat the process for node B, then click OK.

The post Assign Azure IP address appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. Click Virtual machine size.
2. Select the desired disk type (HDD or SSD, although SSD is recommended) and select an Azure instance type to which you wish to deploy FortiGate. Only tested and supported instances appear. If no recommended types appear in the Suggested disk type dropdown list, select View all, then click Select.
   If the desired Azure instance type is not appearing, contact Fortinet Azure support via the information in the marketplace product page. Note certain supported instance types may be removed or added without notification.
3. Click OK to end configuring network and instance settings.

The post Select Azure instance type appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

In the Azure management portal, step 2, Network Settings and Instance, consists of configuring the following:

• Virtual network (VNet)
• Subnets
• VM (Azure instance type)

Some fields are automatically populated with default values. Usually, it is fine to proceed with these values and modification is not needed. These values are are embedded in ARM deployment templates in the backend.

1. Configure the VNet as follows:
   1. Name: change to the desired name. In the example, the name is FortigateProtectedVNet.
   2. Address space: by default, if this is the first FortiGate deployment in the specified resource group, the space is shown as 10.0.0.0/16. You can change this to your own space range depending on your corporate network environment. This value increments with subsequent deployments. For example, the default value for the second deployment would be 10.1.0.0/16.
2. Click OK.
3. Configure subnets as follows:
   1. 1. You will see two subnets: one public-facing subnet, and another protected network subnet. These subnets belong to the VNet address space created in the previous step. By default, the public-facing subnet is 10.0.0.0/24, and the protected network subnet is 10.0.1.0/24. If you change these values, ensure they fit into the address space and that the two subnets do not overlap in the ranges, as a FortiGate instance will sit inline between the two, having two network interfaces (ports).
      2. In this example, the public-facing subnet is named PublicFacingSubnet, and the private subnet (the internal protected network) is named FortigateProtectedSubnet.
      3. If the space is within 10.0.0.0/16 and there are no existing resources in it, the FortiGates’ default private IP addresses will usually be as follows:
         • FortiGate A:
           • Port 1: 10.0.0.4 (PublicFacingSubnet)
           • Port 2: 10.0.1.4 (FortigateProtectedSubnet
         • FortiGate B:
           • Port 1: 10.0.0.5 (PublicFacingSubnet)
           • Port 2: 10.0.1.5 (FortigateProtectedSubnet
4. Note specific IP addresses cannot be seen at this point. Once you are comfortable with the ranges, click OK.

The post Create VNet and subnets in network settings appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. In step 4, Summary, the validation process automatically runs to check if all configuration works.
   If there is no problem, the validation is successful.
2. Depending on your environment, there may be an error upon validation. If this occurs, resolve and start the deployment process again. Common errors are listed in the table below:
   

   Error	Resolution
   Resource usage upper limit is reached	Create an Azure support ticket to increase the quota, or remove existing resources in the same region with the same subscription. In Azure, resources are bound to regions and subscriptions.
   Subscription does not support the purchase	Ask your company’s Azure administrator to enable the purchase on the subscription you selected. Sometimes this may be an Azure IAM access control problem on the subscription, which can be solved by an admin adding your user login account from the Subscription menu.

   Note if an error occurs at this stage, some resources (such as the resource group) will have already been created even without the successful creation of FortiGate instances. You can remove the resources and start over or specify different names next time when you run the deployment process.

The post Validate deployment resources appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. Let’s deploy a Windows server on the VNet’s protected network. In the Azure marketplace, find a Windows 2012 R2 server. Select one with remote desktop login enabled.
   
2. Click Create. Enter the basic parameters. Choose the same resource group and location as the FortiGate, then click OK.
3. Choose an instance type, then click Select.
4. Under network configuration, select the network associated with the FortiGate. In this example, this is FortigateProtectedVNet. Then, select the private subnet (internal protected network). In this example, this is FortigateProtectedSubnet.
5. If you deploy a Windows Server right after deploying FortiGate, the Windows Server’s default IP address is 10.0.1.6, assuming the two FortiGates acquired 10.0.1.4 and 10.0.1.5 on the protected network.
6. There is no need for a public IP address, as the Windows server will be located behind the FortiGates, unavailable for Internet access. Select None.
7. In Network security group settings, ensure TCP port 3389 is allowed in Inbound rules. In this example, it is shown by default, but if not, add it. Click OK.
8. Other configuration is optional. Once everything is confirmed, click OK.
9. Step 4 validates the configuration. Once successfully completed, click Create to deploy Windows Server.
10. Wait for ten to fifteen minutes to complete deployment.
11. Check the IP address for later use.

The post [Use case] Set up a Windows Server in the protected network appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA Active Active for Microsoft Azure using Azure load balancer. See below for the rest of the recipes in this process:

1. Basic concepts
   • Traffic flow
   • Azure load balancer
     • Inbound NAT rules
     • Load balancing rules
2. Locate FortiGate HA for Azure in the Azure portal or Azure marketplace
3. Determine your licensing model
4. Configure FortiGate initial parameters
5. Create VNet and subnets in network settings
6. Select Azure instance type
7. Assign Azure IP address
8. Validate deployment resources
9. Create FortiGate instances
10. Connect to the FortiGate
11. [Use case] Set up a Windows Server in the protected network
12. Configure FortiGate firewall policies and virtual IPs
13. [Failover test] Create load balancing rules and access the Windows Server via remote desktop

1. First, configure FortiGate A. In the FortiGate-VM console, select Policy & Objects > IPv4 Policy and create two new policies, as shown in this example. Create one policy for outgoing traffic from the private subnet, through the public subnet, to the Internet. Create another policy for incoming traffic from the Internet, through the public subnet, to the private subnet.

2. Select Virtual IPs and create a new virtual IP, as shown in the example. This is Static NAT configuration.

3. Edit the second policy. In the Destination field, enter the Windows Server’s IP address. In this example, it is 10.0.1.6.
4. Repeat the same configuration on FortiGate B to have a virtual IP address for RDP and IPv4 firewall policies for incoming and outgoing traffic.

The post Configure FortiGate firewall policies and virtual IPs appeared first on Fortinet Cookbook.

This recipe is part of the process of deploying FortiGate HA for AWS. See below for the rest of the recipes in this process:

1. Customize the CFT template
2. Check the prerequisites
3. Review the network failover diagram
4. Invoke the CFT template
5. Connect to the FortiGates
6. [Connectivity test] Configure FortiGate firewall policy
7. [Failover test] Shut down FortiGate A

Before invoking the CFT template to create FortiGate instances, you must download the original template provided by Fortinet and customize it according to your environment. This recipe covers the following customizations:

• Customization 1: Naming an S3 bucket where FortiGate license and configuration files are placed
• Customization 2: Pointing to the FortiGate AMI located at the desired region

The CFT template is written in JSON. If you modify something, it is recommended you check the syntax using a JSON editor, some of which are available online for free. Fix any errors. Typical errors include missing signs (comma, colon, brackets, backslash, and so on) or incorrect signs (using single instead of double quotation marks).

Customization 1

1. If you purchased Bring Your Own License (BYOL) licenses, register the serial numbers on https://support.fortinet.com and place the two FortiGate license files under the S3 bucket.
   
   The FortiGate license file names must be included in the CFT template. Ensure the bucket is accessible to the AWS account invoking the CFT template. Modify the following lines as shown below. Modified values are shown bolded:

   466     "UserData" : { "Fn::Base64" : { "Fn::Join" : ["",
467          "{\n",
468          "\"bucket\": \"yourbucketname\",\n",
469          "\"region\": \"us-east-2\",\n",
470          "\"license\": \"\/FGVM329999199999.lic\",\n",
471          "\"config\": \"master.txt\"\n",
472          "}\n"
473     ]]}}

   506     "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
507          "{\n",
508          "\"bucket\": \"yourbucketname\",\n",
509          "\"region\": \"us-east-2\",\n",
510          "\"license\": \"\/FGVM32999999998.lic\",\n",
511          "\"config\": \"slave.txt\"\n",
512          "}\n"
513     ]]}}

2. The primary and secondary FortiGate each have a plain text configuration file. You can specify the file name. These files contain FortiGate CLI commands and are triggered for the first time when FortiGate instances boot up. Download the original text files and modify whesre necessary.  The default configuration can function without any modification. You can modify the following:
   1. Hostname
   2. Subnets and IP addresses. These appear on the AWS screen by default. You can enter these values when proceeding with the deployment on AWS. Subnets and IP addresses specified in invoking the CFT template and written in the configuration files must match.
   3. HA group name
   4. Port number (port1, port2, port3, port4), although it is recommended to keep the default purpose of each port:
      1. Port 1 (eth0): public-facing subnet
      2. Port 2 (eth1): internal protected subnet
      3. Port 3 (eth2): heartbeat
      4. Port 4 (eth3): management (access FortiGate via GUI or SSH)

   The below is an example of the configuration file for the primary FortiGate (FortiGate A), with modifications shown bolded. . “Peer IP” is FortiGate B’s port 3 IP address. For the gateway on port 1 and 4 in this example, you can usually specify x.x.x.1 in the subnet:

   config sys glo
set hostname FGT001A-master
end
config system interface
edit port1
set mode static
set ip 192.168.1.13 255.255.255.0
set allowaccess https ping ssh fgfm
set alias external
next
edit port2
set mode static
set ip 192.168.2.13 255.255.255.0
set allowaccess https ping ssh fgfm
set alias internal
next
edit port3
set mode static
set ip 192.168.3.11 255.255.255.0
set allowaccess https ping ssh fgfm
set alias hasync
next
edit port4
set mode static
set ip 192.168.4.11 255.255.255.0
set allowaccess https ping ssh fgfm
set alias hamgmt
next
end
config router static
edit 1
set device port1
set gateway 192.168.1.1
next
end
config system dns
set primary 8.8.8.8
end
config firewall policy
    edit 0
        set name "outgoing"
        set srcintf "port2"
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set nat enable
    next
end
config system ha
    set group-name "test001”
    set mode a-p
    set hbdev "port3" 50
    set session-pickup enable
    set ha-mgmt-status enable
    config ha-mgmt-interface
        edit 1
            set interface port4
            set gateway 192.168.4.1
        next
    end
    set override disable
    set priority 255
    set unicast-hb enable
    set unicast-hb-peerip 192.168.3.12


   The below is an example of the configuration file for the secondary FortiGate (FortiGate B), with modifications shown bolded. The hostname, ports, IP addresses, netmasks, first firewall policy name, HA group name, and so on should all be identical to the primary FortiGate’s. Change the peer IP address of the heartbeat. This is FortiGate A’s port3 IP address. For the gateway on ports 1 and 4 in this example, you can usually specify x.x.x.1 in the subnet:

   config sys glo
set hostname FGT001B-slave
end
config system interface
edit port1
set mode static
set ip 192.168.1.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias external
next
edit port2
set mode static
set ip 192.168.2.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias internal
next
edit port3
set mode static
set ip 192.168.3.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias hasync
next
edit port4
set mode static
set ip 192.168.4.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias hamgmt
next
end
config router static
edit 1
set device port1
set gateway 192.168.1.1
next
end
config system dns
set primary 8.8.8.8
end
config firewall policy
    edit 0
        set name "outgoing"
        set srcintf "port2"
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set nat enable
    next
end
config system ha
    set group-name "test001”
    set mode a-p
    set hbdev "port3" 50
    set session-pickup enable
    set ha-mgmt-status enable
    config ha-mgmt-interface
        edit 1
            set interface port4
            set gateway 192.168.4.1
        next
    end
    set override disable
    set priority 1
    set unicast-hb enable
    set unicast-hb-peerip 192.168.3.11
end

Customization 2

You must modify the CFT template to point to the FortiGate AMI located at the same region. The FortiGate AMI image is publicly available. You must obtain the region name and the AMI ID.

1. Find your region name at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions.
2. Find the FortiGate AMI ID made public in the selected region. You can find this ID in the list file linked here.
3. Modify the line that shows the region us-east-x and the AMI ID ami-xxxx with the ones found in step 1 and 2 above. In the example, this is line 131, but may differ in your case. Modifications are shown bolded:

   129 "Mappings" : {
130     "RegionMap" : {
131          "us-east-2"      : { "fgtami" : "ami-1c260d79"}
132          }},

The post Customize the CFT template appeared first on Fortinet Cookbook.

This recipe introduces the process of deploying FortiGate Active-Passive High Availability (HA) for AWS. See below for recipes in this process:

1. Customize the CFT template
2. Check the prerequisites
3. Review the network failover diagram
4. Invoke the CFT template
5. Connect to the FortiGates
6. [Connectivity test] Configure FortiGate firewall policy
7. [Failover test] Shut down FortiGate A

FortiGate supports Active-Passive HA on AWS, with two FortiGate instances synchronizing configuration and sessions with FortiOS versions 5.4.5 and 5.6.3+. This FortiGate native mechanism achieves HA without using AWS clustering/balancing technologies. One instance runs as the primary/master, while the other runs as the secondary/slave (hereafter referred to as “primary”/”FortiGate A” and “secondary”/”FortiGate B”, respectively). When the primary fails to operate, the secondary automatically promotes itself to the primary.

To deploy this HA, you will generally not subscribe FortiGate EC2 instances from the AWS marketplace portal. Instead, you will kick off deployment using CloudFormation templates (CFT).

See below for FortiGate product listings on AWS:

• BYOL: https://aws.amazon.com/marketplace/pp/B00ISG1GUG
• On-Demand: https://aws.amazon.com/marketplace/pp/B00PCZSWDA

The post Deploying FortiGate Active-Passive HA for AWS (Unicast HA) appeared first on Fortinet Cookbook.