Welcome to this new blog series, centered around Transit VPC. In 2017, I presented you with a four blog series on Transit VPC using Juniper Networks’ vSRX firewall at the crux of it managing the routing and security policies. In this blog series, I’d like to talk about our experience with deploying a Transit VPC solution using Palo Alto Networks’ VM-Series Next-Gen firewall inside AWS; a project I designed, implemented, tested, documented and delivered. This blog is part 1 of the series.
In this blog series, I shall be covering the following topics:
1. Revisit concept of Transit VPCs
2. The technical use cases of having Transit VPCs
3. Why we chose to use Palo Alto Networks VM-series as our hub firewall
4. How we pieced it all together
To jog you through what a Transit VPC is – it is a concept of having a Virtual Private Cloud (VPC) network with virtualized firewalls hosted inside Amazon.com’s cloud computing platform, Amazon Web Services (AWS). The Transit VPC acts as the Hub for all the traffic passing between the Application VPCs and the On-Premise customer datacenter. Thus, traffic between App-VPC-1 and On-Premise datacenter passes through the Transit VPC; as well as the traffic between App-VPC-2 and App-VPC-4, and so on.
At a high level, the diagram below shows the hub & spoke representation between the Transit VPC, the Application VPCs and the On-Premise datacenter currently in place. The On-Premise customer datacenter too is a “Spoke” from the perspective of the Transit VPC, with similar security and routing policies applied to it.
The Transit VPC (just like any other VPC created inside an AWS environment) consists of a network, which is defined by a supernet CIDR that is split into multiple subnets as desired. Each of these subnets is then, in turn, associated with their own route tables and security groups. The Transit VPC is defined for an AWS Region, with the VPC subnets being equally divided amongst two or more Availability Zones per Region, which helps provide redundancy and high-availability.
The use case here once again is providing the network operators and the security teams with a single pane of glass for the traffic traversing between their Applications (like Apache Web Server, Jira, Splunk, etc.) and their databases – where both are residing in different VPCs, or the communication from their Corporate HQ in US and their APAC Data Center. This provides a robust highly-available and scalable security framework in the virtualized firewalls running in a public cloud environment.
This brings us to the question of why did we choose the Palo Alto Networks VM-series firewall solution, having previously worked with another vendor’s virtual firewall in a similar Transit VPC concept. To which, I’d say let’s talk about the use case of this project. We conceptualised this solution for our customer as a one-stop solution to their security requirements – which included acting as the Hub and passing all the networking traffic through it between different Application VPCs. Furthermore, to allow remote users to connect to it over SSL-VPN, perform Web Application Filtering, and implement aspects of Network Data Loss Prevention – all while giving us the granularity of monitoring each packet and turning the knobs as required. The Palo Alto Networks VM-series firewall fits the bill with the features.
How did we piece this solution together? Well, let’s keep that for the next blog post, shall we? To learn more about how we pieced this all together, please stay tuned for blog # 2 of this series. At a high-level, we used only some parts of the solution used before.
The Application VPCs already existed. Therefore, our implementation focus was on the following:
1. Creation of the Transit VPC.
2. Creation and configuration of Virtual firewall instances in Transit VPC.
3. Running BGP over IPSec VPN with the Application VPCs.
4. Changing the routing to make these firewall instances as the default gateway for all traffic to and from the web servers.
5. Configure security policies and NAT policies for restricted access.
We also deterministically configured the two PAN firewalls to avoid asymmetric routing caused by both firewalls advertising the default route to the Application VPCs.
Until next time then, pip pip.
For more details about this successful project, reach out to us at firstname.lastname@example.org.
To read the previous blog series of setting Transit VPC using Juniper vSRX firewall instances as the Hub can be found at https://www.serro.com/resources/blogs/aws-transit-vpc/.
About the Author:
Shreyans is a Solutions Engineer at Serro, been with the team since early 2014. He has a Master of Science in Electrical Engineering degree from San Jose State University. His experience includes enterprise, data center and service provider routing, switching and security solutions across multiple vendors – Juniper Networks, Cisco, Palo Alto Networks, Brocade and Huawei; as well as cloud computing solutions like Amazon Web Services and OpenStack. In his free time, Shreyans takes pictures of landscapes around the Bay Area, with the Golden Gate Bridge being his muse. He can be found on social media on LinkedIn, and on Instagram.