Amazon VPC Ingress Routing - New Network Security Use Cases

The introduction of Amazon Virtual Private Cloud (Amazon VPC) Ingress Routing (IR) to the AWS Networking stack introduces the ability to build more flexible, yet granularly-controlled network security solutions in AWS. 

What is VPC in AWS?

Amazon VPC Ingress Routing is a service that helps customers simplify the integration of network and security appliances within their network topology. 

With Amazon VPC Ingress Routing, customers can define routing rules at the Internet Gateway (IGW) and Virtual Private Gateway (VGW) to redirect ingress traffic to third-party appliances, before it reaches the final destination. This makes it easier for customers to deploy production-grade applications with the networking and security services they require within their Amazon VPC.

Fortinet and AWS Use Cases

These enhancements are particularly valuable for organizations that implement multi-layer security solutions from both AWS and Fortinet. The VPC IR affects two main network security virtual appliance use cases:

1. Placing a FortiGate-VM or FortiWeb-VM alongside workloads in the same VPC while selectively routing ingress traffic destined to protected workloads through the relevant Fortinet Network Virtual Appliances (NVA); and
2. Forcing all traffic entering a VPC to always route through a FortiGate-VM eliminating the concerns of unsecure traffic.

The Fortinet products that can be implemented using VPC IR are primarily FortiGate-VM Next-Gen Firewall, FortiWeb-VM Web Application Firewall and FortiSandbox in routed mode. 

In a single VPC Scenario, there could potentially be different protected assets that each require different security policies or even a different security protection type located in the same VPC. For example, an application could be a web application that has multiple service components such as payments, registration, and file uploads. Using CIDR blocks with a 32 prefix, one can route traffic to the payments service through a FortiWeb-VM, traffic to the file upload server through the FortiSandbox-VM, and traffic to the other services simply through the FortiGate-VM for IPS signatures.

The following diagram illustrates the route tables associated with the VPC which in this case has 4 subnets. Both the FortiGate and the FortiWeb have an external elastic network interface (ENI) that is associated with the overall VPC network, as well as an internal ENI that is associated with protected resources subnets for Web and Payments respectively. In this scenario whenever the Internet Gateway (after performing the EIP to internal IP NAT) receives traffic with a destination to the web servers’ network, 10.0.2.0/24 it will be routed to the FortiGate-VM whereas when traffic has the destination of the payment’s server network, it will be routed to the FortiWeb. Interestingly enough, there is no need to perform NAT on the Fortinet Network Virtual Appliances allowing for a much easier separation of networking and connectivity management from security management.

The second use case is simpler in nature, as it involves only a single VPC and FortiGate, but the simplicity is really what provides much of its value. Prior to the VPC IR capability, one could not enforce the use of a FortiGate to protect all traffic into and out of a VPC. Any user that has the permissions to create an instance, could spin up a new instance and directly connect it to the internet via the internet gateway. With VPC Ingress routing, the IGW has a route table of its own, which is not something any user will mistakenly manipulate. The ingress routes can be configured to route all ingress traffic to a FortiGate-VM and therefore ingress traffic will always be forwarded to the FortiGate-VM even if a user doesn’t specifically associate the appropriate route table to his newly created instance. As a result, traffic that leaves ingress to the internet directly via the IGW will still get firewalled in the return path back into the VPC eliminating the situation where an instance can potentially gain unprotected access to the internet.

The following diagram illustrates the simplicity of making traffic always route through the FortiGate-VM for any inbound traffic. All incoming traffic which has likely been translated from an EIP to an internal address, let’s assume in the 10.0.0.0/17 subnet, will first be routed by the IGW to ENI-1234 of the FortiGate-VM. And then the FortiGate-VM will forward this traffic to the relevant server, whether web server or payments server. The return traffic from the servers uses the internal subnet route table to determine that its next hop is the FortiGate-VM, and then the FortiGate-VM determines its next hop as the IGW. There is no change in the ingress portion, however the fact that the IGW will always forward traffic that is destined to the servers in network 10.0.0.0/17 to the FortiGate-VM effectively ensures that no server is placed in this subnet without a security policy.

The Benefits of Using Amazon VPC Ingress Routing with Fortinet 

To summarize – VPC IR is a great step to add a layer of flexibility for customers. This helps organizations design more secure and more operationally viable security solutions in their AWS-based infrastructure. To summarize, the three main benefits are: 

1. Separation of network management and security management by eliminating the need for NAT in different scenarios.

2. Adding the ability to force ingress traffic to protected/sensitive networks through a FortiGate-VM.

3. Allowing for granular security enforcement to be assigned on a per subnet basis vs. at the entire VPC level. 

Fortinet is committed to supporting new developments from AWS in order to help customers better realize the potential cloud computing can offer to accelerate their business.

Learn how Fortinet’s adaptive cloud security solutions provide increased visibility and control across cloud infrastructures, enabling secure applications and connectivity from data center to cloud.