As organizations adopt a comprehensive teleworking policy, creating a reliable, scalable, and secure connectivity solution for their expanded remote workforce has become extremely important. Many organizations have already migrated some or all of their workloads and applications to Amazon Web Services (AWS) to take advantage of the elasticity, reliability and scalability of the public cloud. As a result, customers demand a solution that not only integrates with AWS native services, but also enables their remote workforce to connect to enterprise applications deployed in hybrid cloud environments in an agile and reliable manner.
Fortinet Next Generation Firewall (NGFW) Virtual Appliance is available in the AWS Marketplace. The FortiGate NGFW supports various Amazon EC2 (Elastic Compute Cloud) instance types and configurations to offer customers scalable SSL VPN and IPSec capabilities. This allows hundreds of users to concurrently and securely connect to applications deployed in their AWS accounts via an encrypted connection (like IPSec or SSL). Additionally, FortiGate-VM leverages AWS c5n instances to distribute packet processing workloads across all available vCPUs. It also leverages the redundancy and resiliency of AWS to ensure business continuity in the event of a natural disaster. In this blog, we will discuss some of the design considerations to deploy a scalable, secure solution in AWS using FortiGate-VMs. We will also outline how the solution can be launched in AWS.
Multi-Region Deployment with AWS Transit Gateway and AWS Route 53
While there are different ways to design a resilient architecture in AWS, most designs consider deploying services in at least two AWS regions to enable disaster recovery and avoid service disruption in the event of a natural disaster, such as an earthquake. Additionally, by deploying resources in two or more availability zones within an AWS region, customers can ensure fault tolerance. Figure 1 depicts a multi-region FortiGate deployment that leverages AWS Route 53 to help connect SSL clients (FortiClient) to a region with the least latency. In this architecture, two regional cloud security services hubs (us-east-1 and us-west-1) have been deployed. Each cloud security services hub is comprised of two FortiGate instances.
Figure 1. Multi-region teleworker deployment with FortiGate-VM and AWS Route 53
As shown, Route 53 enables VPN clients to get an IP address from a FortiGate endpoint to terminate VPN connections based on latency. In addition to regional redundancy, an AWS design best practice includes deploying at least two FortiGates, each in a distinct availability zone. Multiple FortiGate design options, such as active/active and active/passive, are available. Multivalue Answer Routing in Route 53 can be used to distribute the IPSec VPN traffic across FortiGates in each region, as shown in Figure 1.
Most customers deploy applications in multiple VPCs that need to be accessible by remote clients. AWS recommends leveraging the AWS Transit Gateway for connectivity between centralized shared services VPC and all application VPCs. As depicted in Figure 2, FortiGate-VMs in the cloud security services hub can be connected to an application VPC via an AWS Transit Gateway. In this architecture, an AWS NLB load balances SSL VPN traffic across the two FortiGates in the hub VPC using 5 tuple hash (Source IP/Destination IP, Source Port/Destination Port and Protocol).
As shown in Figure 2, two subnets in the cloud security services hub terminate VPC attachments connected to the Transit Gateway. Once SSL VPN tunnels are terminated at one of the FortiGates, remote users can then access applications deployed in the application VPCs. For example, if a remote user needs to access a workload in the Application VPC B, a specific route (10.20.0.0/16) in the private subnet’s route table will be used and the traffic will be routed to the transit gateway via a Transit Gateway attachment as shown in Figure 2. Note that the route table in each private subnet contains routes to the application VPCs via the Transit Gateway attachment. Additionally, they contain a default gateway route that points to the FortiGates’ private ENI in each availability zone. The return traffic will be routed via transit gateway back to the hub VPC. The route table in the FortiGate entry subnet, where the VPC attachment is terminated, has the default gateway set to the private ENI of the FortiGate – this way, the return traffic can take the same path back to the remote user. Customers can create IPSec VPN connections from their on-premises to FortiGates in the Hub VPC or Transit Gateway. This will enable remote users to access the on-premises resources as well.
Figure 2. Remote Access SSL VPN with FortiGate-VM and AWS Transit Gateway
Additional Design Considerations
The architectures discussed earlier in this document are meant to provide a reference design for a scalable teleworker solution in AWS. However, there may be additional important design considerations that need to be accounted for when deploying the solution in your AWS environment. These may include:
- Scaling out with FortiGate Autoscaling – Customers can deploy a FortiGate ASG integrated with the AWS transit gateway. This feature is built into the FortiOS (FortiGate’s purpose-built operating system) to allow for a smooth scale in/scale out solution. This can be deployed using a CloudFormation template available at Fortinet’s official GitHub repository.
- Inside tunnel CIDR (classless inter-domain routing) – Plan your hub VPC CIDR (where the FortiGates reside) to accommodate all remote clients. For instance, if you expect 300 employees to connect to a FortiGate, a VPC with /24 CIDR won’t have enough IP addresses for one to be allocated to each client. Although it is possible to apply source NAT at each FortiGate, it is generally not a recommended practice since many organizations require full client visibility.
- FortiGate instance type/size – as mentioned previously, there are several different instance types/sizes of FortiGate solutions available in the AWS Marketplace. FortiGate-VM can achieve the best performance (up to 20Gbps IPSec traffic ) when turned on with the C5n.18xlarge instance due to the enhanced networking capability that the FortiGate-VM can fully achieve, as well as other optimizations such as auto CPU affinity. Note that to support a greater number of tunnels and higher throughput, a FortiGate-VM can be scaled up to a higher instance size.
Launching FortiGate-VM from AWS Marketplace
To launch a FortiGate-VM from the AWS console, log in to the AWS Management Console, select the AWS region where your resources are located, and navigate to EC2 landing page. Click on launch instance and enter FortiGate in the search field. This will bring up the associated links in the AWS Marketplace. Click on the link to choose the FortiGate-VM.
FortiGate-VM for AWS supports both on-demand licensing and bring-your-own-license (BYOL) models. The On-Demand Model offers a free trial that will let users try FortiGate-VM in AWS without incurring software charges. You can choose the licensing model that best suits your licensing needs.
Once you select the right Amazon machine image (ami) for the FortiGate-VM, you can subscribe to the Fortinet FortiGate Next Generation Firewall software and click on Continue. At that point, it will let you select the instance type for your FortiGate-VM. Fortinet supports a wide variety of instance types in AWS, ranging from 1 vCPU t2.small to 72 vCPU C5n.18xlarge instances. Fortinet strongly recommends utilizing the C5n instance type to take advantage of AWS enhanced networking to achieve maximum network throughput. In the next step, choose the VPC where you want to deploy the instance and the subnets that you want the FortiGate-VM instance to be deployed in.
Figure 3. Choosing an instance size when launching FortiGate in AWS
You can leave the storage (Step 4) and tags (Step 5) as default, and navigate to the Security Groups section. Once there, click on Create New, choose a name for the security group, and add the ports that you intend to use for managing the firewall as well as the ports used for traffic. By default, the recommended FortiGate ports will have HTTP (TCP Port 80), HTTPS (TCP port 443), SSH(TCP Port 22), and other management ports. For SSL-VPN, you can use 10433 or any other custom port other than 443, since 443 is used for FortiGate’s HTTPS management.
Choose “save” once all the required ports are added to the security group along with the right source. The source can be anywhere (0.0.0.0/0 and ::/0) for SSL-VPN, or a specific range of IP addresses for things like source IP access control. The next step is to select the key pair. For key pairs, you can select an existing key pair or choose “Create a key pair in EC2” to create a new key pair. The public key will be added to the EC2 instance, which allows you to access the instance using the corresponding private key. After making the selection, review all the settings and launch the instance.
Figure 4. Adding inbound rules to a Security Group
Once your FortiGate-VM instance is running, associate an Elastic IP address to the internet facing interface of that instance. The Elastic IP will be used to manage the FortiGate-VM (on HTTPS) and to complete the configuration of IPSec/SSL-VPN. IPSec VPN uses UDP port 500 and 4500 (if NAT is used). Allow these ports in the security groups if you choose to use IPSec VPN for remote access. SSL-VPN users would also be using the Elastic IP on the custom port that was selected for SSL-VPN in the security Group. A single FortiGate-VM in AWS for SSL-VPN solution would be a single point of failure, so to provide high availability, fault tolerance, and resiliency we recommend deploying a FortiGate HA Cluster across multiple availability zones in a single region.
To provide disaster recovery, the same setup can be replicated in another region, with the traffic load balanced by Amazon Route53. Amazon Route53 supports multiple routing policies one of which is latency-based routing policy which serves the user’s requests from the AWS region that has the lowest latency. Within each region, additional record sets can be created with multivalue answer routing to load balance connections to the FortiGates. Multivalue answer routing policy let’s users configure Amazon Route53 to return multiple values in response to DNS queries. Detailed information about Amazon Route53’s latency based routing can be found here. To configure multivalue answer routing, refer to the documentation here. Traditionally, FortiGate’s clustering protocols work over multicast, but in AWS the configuration synchronization happens over unicast (UDP and TCP). It also leverages AWS features like AWS Lambda, API Gateway, and CloudWatch metrics for the failover process.
In a FortiGate (Active-Active) A-A solution in AWS, FortiGates are launched in two different availability zones. This solution does not provide failover for ingress traffic, as this should be handled by external resources such as AWS ELB or Route53 services. In a FortiGate (Active-Passive) A-P solution in AWS, FortiGates are launched in two different availability zones. During failover, the Elastic IP of the Active Device is disassociated from the Active FortiGate and associated with the Passive FortiGate. In both Active-Active and Active-Passive soltuions, if one of the FortiGate-VM fails, the route tables for the private, protected subnets are also changed so that the traffic now flows to the active FortiGate-VM.
FortiGate NGFW Active-Active Solution can be deployed using a CloudFormation template from Fortinet’s official GitHub repository. FortiGate NGFW Active-Passive Solution can also be deployed using the related CloudFormation template from Fortinet’s official GitHub repository.
Virtual Private Network
Virtual Private Networks (VPN) let sites and users connect to private networks over the public network (internet) to gain secure access to their resources. Instead of using expensive leased lines or other infrastructure, organizations can use utilize the relatively inexpensive, high-bandwidth internet. Since the internet is universally readily available, VPNs are used extensively for remote connectivity both for site-to-site and remote access VPNs. Two of the most used types of remote access VPNs are IPSec and SSL-VPN.
A managed client-based VPN service provided by AWS is the AWS Client VPN. It enables you to securely access your AWS resources as well as datacenter environments. FortiClient is Fortinet’s Client VPN software, and the added value FortiClient brings is in its embedded security features, increased flexibility and configurability, and lesser restrictions on the client computers and networks.
Remote Access to Data Center Networks via VPN Through FortiGate-VM in AWS
FortiGate-VM can act as an SSL-VPN Gateway and IPSec VPN Gateway to terminate AWS VPN connections. The FortiClient software that runs on the Client computer manages all the details of encrypting, encapsulating, and sending packets to the remote VPN gateway (a FortiGate-VM in AWS).
Users who can connect to VPN should be defined on the firewall. The user configuration becomes much simpler if you integrate it with existing authentication servers through LDAP or RADIUS. Integrating with existing authentication servers, such as Windows AD, lowers the chance of making mistakes in the configuration of users and user groups.
FortiToken can be used for two-factor authentication (2FA) to ensure that the end-user is who they claim to be by requiring authentication information as well as a dynamic token code that FortiToken Generates.
Split tunneling lets users access the corporate network through the VPN but still access the internet – which is prevented from going through the SSL VPN tunnel. Split tunneling can be enabled on FortiGate-VM for both SSL VPN and IPSec VPN.
IPSec VPN
On the Client computer, the FortiClient application acts as the local VPN gateway. Packets destined for the AWS VPC networks are encrypted, encapsulated into IPSec packets, and sent through the VPN tunnel to the FortiGate unit. Packets for other destinations are routed to the internet as usual. IPSec packets arriving through the tunnel are decrypted to uncover the original IP packets.
This document shows how to configure FortiGate-VM to act as a VPN Gateway.
The following configuration enables split tunneling for the VPN connections in the phase 1 configuration:
config vpn ipsec phase1-interface
edit “for_AWS”
set ipv4-split-include “local_network”
next
end
Also, using chacha20 as the encryption mode in phase 2 improves the IPSec connection performance. It can be enabled in phase2 config, as shown below.
config vpn ipsec phase2-interface
edit “for_AWS_Ph2”
set proposal chacha20poly1305
next
end
With firmware release 6.2.3, we have added auto-affinity to spread the load of encrypting and decrypting IPSec packets across available vCPUs.
With the FortiGate hardware platform, it is possible to offload IPSec processing to a specific ASIC. In a virtualized environment like the public cloud, FortiOS does not have access to hardware acceleration. To optimize IPSec encryption and decryption through a FortiGate-VM running in AWS, a user has to disable the software decryption asynchronization that is used by the FortiGate hardware platforms.
config system global set ipsec-soft-dec-async disableend
If the number of IPSec connections or throughput requirements increase, FortiGate-VM can be scaled up to a higher instance type to get IPSec throughput as high as 20Gbps and also support more IPSec connections. This is made possible by selecting the correct instance type and also configuring the IPSec optimizations above. FortiGate’s IPSec throughput can reach up to 20 Gbps. One instance type that can achieve that throughput in AWS is C5n.18xlarge, which uses an Intel Xeon Platinum 8124M (turbo GHz 3.5) processor.
SSL-VPN
There are two modes of operation for SSL-VPN, which include tunnel mode and web mode.
SSL-VPN Tunnel Mode: In this mode, once the tunnel is established between the client and the FortiGate-VM in AWS, the SSL VPN client encrypts all traffic from the remote client computer and sends it to the FortiGate-VM through the SSL VPN tunnel. This mode provides a transparent experience for the end user. There is no proxying done on the FortiGate, and it can be used for accessing a wide range of applications.
Enabling split tunneling for tunnel mode in SSL-VPN is done at the portal level.
config vpn ssl web portal
edit “aws-ssl-portal”
set tunnel-mode enable
set split-tunneling enable
set split-tunneling-routing-address “10.212.1.0”
set ip-pools “SSLVPN_TUNNEL_ADDR1”
next
end
SSL-VPN Web mode: In web mode, there is no need for an SSL-VPN client on the client computer. It is a clientless access mode that allows network access using a web browser and its built-in SSL encryption. Remote Users can authenticate to FortiGate-VM’s SSL VPN Web Portal, which provides access to network services and resources, including HTTP/HTTPS, Telnet, FTP, SMB/CIFS, VNC, RDP, and SSH. When a user starts a connection to a server from the web portal, FortiOS proxies this communication to the requested resources.
Since Web mode proxies all its communication through the FortiGate-VM, it places an overhead on the FortiGate’s resources and supports only certain applications. For most teleworkers who remain connected through the VPN for longer periods, Tunnel mode is the better option. It is transparent to the user after a successful connection and it allows the users and networks to exchange a wide range of traffic regardless of protocols or applications.
This link has the instructions for configuring the FortiGate-VM and the FortiClient software for remote access through SSL-VPN in split tunnel mode.
In our design depicted earlier in this document, we showed end users connecting to the FortiGate-VM in AWS through SSL-VPN and then allowing them to access the on-premises networks through Direct Connect or VPN. This document shows how to configure SSL-VPN to IPSec VPN for such a use case.
SSL VPN operates on HTTPS protocol at Layer 7. If the FortiGate-VM in AWS needs to handle a large number of SSL-VPN connections, you can scale out the FortiGate-VM in an autoscaling group and use an Application Load Balancer to load balance the SSL-VPN connections between the FortiGate-VMs, as explained in the “additional design considerations” section of this document.
Conclusion
In this blog post, we discussed how organizations can leverage FortiGate-VM in AWS to provide teleworkers with secure connectivity and best-in-class network throughout. FortiGate-VM’s integration with native AWS services such as Transit Gateway and Route 53, as well as important design considerations were explained. Finally, we outlined steps to launch FortiGate-VM in AWS, and the configurations required to take advantage of FortiGate-VM’s optimization features. The Fortinet teleworker solution enables organizations to securely connect their remote workforce to AWS workloads and applications, and ensures business continuity by leveraging the purpose-built FortiOS software as well as the scale and resiliency of AWS.
Discover how Fortinet Teleworker Solutions enable secure remote access at scale to support employees with a wide array of access requirements.
Learn how Fortinet’s dynamic cloud security solutions provide increased visibility and control across cloud infrastructures, enabling secure applications and connectivity from data center to cloud.
Read these customer case studies to see how Cuebiq and Steelcase implement Fortinet’s dynamic cloud security solutions for secure connectivity from data center to the cloud.
Engage in our Fortinet user community (Fuse). Share ideas and feedback, learn more about our products and technology, or connect with peers.
As Fortinet partners, Net Universe offers all Fortinet devices and subscriptions with worldwide Delivery Services.
Send us an email to [email protected] for more information or visit https://www.netuniversecorp.com/fortinet.
You can visit our Shop Online
