Aviatrix providers a solution to protect public-facing applications and services with its IPS capabilities. Aviatrix IPS solution is also known as the “Public Subnet Filtering” solution.
Please listen to this ~2 min long video as refresher on this topic.
I also created a lab showcasing the configuration, routing and forwarding details for a real enterprise use-case.
Q: Where can I see those IPs being blocked in Aviatrix Controller?
Aviatrix has a L4 stateful firewall that is enabled on the PSF-GW when the IPS feature is enabled. This L4 stateful firewall blocks the malicious IP addresses. This feature does not depend on the EC2 “Security Group” which allows limited number of rules to be programmed.
Note that 10.19.0.43 is the IP address of the PSF-GW itself.
Q: Some IP addresses are well-known and not malicious. Why AWS GuardDuty is marking them as malicious and how do I fix this?
This is a well-known observation with AWS GuardDuty that rarely, it could mark some good IPs as malicious IPs. The fix is very simple. You can exclude those from the Aviatrix GuardDuty database. With this method, Aviatrix will not block those IPs.
For example we excluded 80.82.77.33 from the finding list.
Now after the exclusion list was created, Aviatrix removed the block rule from its PSF-GW for this IP address. You can observe this change from the following screen shot as well.
Aviatrix is modern born in the cloud for the cloud security platform. Unlike legacy vendors, Aviatrix Security is bolted on the platform itself. It is a pervasive security platform that also provides a framework for other vendors to integrate. This in turn provides the best possible security posture for the enterprises.
This post highlights some of the most important security features Aviatrix offers. This is by no means an exhaustive list. Visit https://aviatirx.com and https://docs.aviatrix.com for a comprehensive list
Aviatrix Security Feature List
Encryption
Standard IPSec
Patented High-Performance IPSec
Egress Security
Secure Egress with FQDN Filtering
Ingress Security
Provided by integrating AWS GuardDuty
L4 Stateful Firewall
Cloud Security Framework (FireNet) The framework covers many security features by partnering with 3rd party vendors such as
Check Point
Cisco FirePower
FortiNet
Palo Alto Network
Secure Network Segmentation
Multi-Cloud with Aviatrix Transit
AWS TGW
Secure Private Service Access
Private S3 Access
Secure Cloud Access On-prem users, Branches, and Data Centers, all need to access the Cloud resources. The Center of gravity is in the cloud. Aviatrix Secure Cloud Access provides features such as Secure Cloud User Access and Secure Site Access. Secure Site Access also covers connecting to SD-WAN branches and sites from Cloud.
Compliance and Visibility
CoPilot visualization, flow analysis is critical for securing the infrastructure. CoPilot helping enterprises identify rouge VPCs, detecting DDOS and anomalies
Cloud and SaaS has eaten the SD-WAN lunch and SD-WAN did not compliant 🙂
SD-WAN submitted to CSP
SD-WAN party is over too soon
Cloud is the Network and Cloud is the WAN
NCC. vWAN, AWS TGW Connect, these are all example of CSP taking over and “killing” SD-WAN.
With SaaS why someone would need an expensive physical SD-WAN branch router? Application are accessed over the Internet in SaaS model. No need for PCoIP, RDP or VDI etc. Look at the shrinking Citrix and VMware VDI solution market.
Branch already moved into the Cloud so why one would need SD-WAN.
Internet is reliable than ever before.
Look around, all SD-WAN vendors are gone, their talent moved on to Multi-Cloud Networking bandwagon. Hardware vendors have no clue where to go, and what to do. Acquisiotion season is coming to acquire half backed multi-cloud startups, like it was four years ago to acquire half-backed SD-WAN vendors/
One name emerges and stand out, that is Aviatrix. Full-stack, Multi-Cloud Networking and Security solution.
GCP Global VPC is a great technology and really a powerful concept but it is not a good design choice for enterprise networks. It is a loaded statement. First, let us understand GCP Global VPC.
What is Global VPC?
Imagine you have a big basket (VPC) that spans across the planet. You put all your eggs (workload) in that basket. Now, these different colored eggs (workloads in different subnets in different regions) are magically allowed to talk to each other (unless you manually create the firewall rules) across the planet. It is indeed powerful yet at the same time scary.
GCP Global VPC is different than other Clouds such as AWS. In AWS all VPCs are regional. In GCP all VPCs are global in nature. There is no knob to turn the feature ON or OFF.
Huge Failure Domain or Blast Radius
Global VPC has a huge blast radius or failure domain. The lateral movement of the bad actors within the VPC will be a huge issue. If a VM is compromised, it can potentially harm other VMs as well. You need more VPC to contain the blast radius. A VM in Singapore can talk to another VM in Oregon region without any restriction from a routing perspective. It is true that one can create the “GCP L4 Firewall Rules” to block the traffic, but it is painful to manage and also you need NGFW to be inserted for your important and Prod. VMs/K8S/etc.
Service Insertion – Not Possible
In Global VPC it is not possible to insert 3rd party services in the traffic flows. Services such as Next-Generation Firewall, Load Balancer etc. This is due to the fact that your source and destination VM is now sitting in this giant global VPC and if you try to put the traffic over to a VM in a different VPC or same VPC you will not be able to do that. The native VPC router will take precedence at that point and just route the traffic using the GCP fabric.
Air Gaping, DMZ or Networking Segmentation – Not Possible
The same technical reason as I mentioned before applies here too. With Global VPC it is not possible to create DMZ or network segments inside the VPC itself. You would need more VPCs in order to create segments or air gaps between your applications such as Prod/Dev/SRE/etc.
Compliance and Governance
This is a major headache with Global VPC for large enterprises. You can elevate some of it by using the GCP Shared VPC model but what I have seen is that a customer would again use a single Global VPC with Shared VPC and they will use it as a Transit/Hub replacements.
What are the Best Practices?
GCP recommends a balanced approach for enterprises. For small companies with a few workloads, it might be ok to use a single Global VPC, but for enterprises, it is not a good design choice.
Single Global VPC is Not a Good Design for Enterprises
This is also recommneded by GCP to create more VPC for network security, scale, cost optimization, etc. purposes.
Factors that might lead you to create additional VPC networks include scale, network security, financial considerations, operational requirements, and identity and access management (IAM).
Create Regional VPC
When you create a GCP VPC, it is global by default. There is no knob option that turn this off. So how would you create regional VPC?
When you create the VPC, you need to make sure the subnets stay within the same region. For example for VPC in US-West region, you need to make sure you are not adding subnets from Singapore region.
Avoid VPC Sprawl
VPC sprawl is not a good design practice. We have seen enterprise customers where they allocate one VPC per account in AWS as an example. This would create management, compliance, and operational overhead. This could potentially lead to an expensive design too due to cross VPC and cross-region charges.
At the same time it not a good design to just use one single giant global VPC for all types of workloads for all LOB and teams. Avoid the VPC sprawl and strike a balance.
Use Multiple VPCs for Segmentation and Air Gaping
The best practice is to use additional VPCs for proper segmentation, security, air gaping, network segmentation, etc. GCP also recommends using a hub and spoke model like what you would see in other Clouds as well.
Some large enterprise deployments involve autonomous teams that each require full control over their respective VPC networks. You can meet this requirement by creating a VPC network for each business unit, with shared services in a common VPC network (for example, analytic tools, CI/CD pipeline and build machines, DNS/Directory services).
Encryption is Best Effort inside the VPC
GCP does not guarantee encryption for traffic inside the VPC. It means if you have one single global VPC, all the workloads could be talking to each other without encryption. This is true for traffic between subnets of different regions inside a global VPC.
This is very risky and dangerous. Just imagine some dev. workload sniffing the un-encrypted data. I understand that your application should be TLS encrypted but if a breach happens who will be responsible? It is the responsibility of the NetSec architect. When it comes to security, the more is better with the Zero-Trust mindset.
Data in transit within these physical boundaries is generally authenticated, but may not be encrypted by default – you can choose which additional security measures to apply based on your threat model.
Aviatrix follows the Zero-Trust model and defence in depth approach. This is applicable for encryption as well. Hence Aviatrix Cloud Network are encrypted by default.
VPC Peering Quota
The max peering limit is 25. Aviatrix encrypted peering is better choice.
Be mindful of the GCP route limit. Which is 500 by default. It can be increased. GCP did not publish the max limit. My request for 1000 routes per project was approved within minutes. In any case, be careful about those limits.
The Google Cloud Interconnect (GCI) is a great service to provide hybrid connectivity back to the on-premises DCs. For example, Enterprise can get 10 Gbps GCI connections for their on-prem to GCP migration needs. The challenge is that GCI is not encrypted and the native IPSec encryption only provides 1.25Gbps
HPE is also available for a Multi-cloud Transit solution. For performance benchmarks, refer to GCP Insane Mode performance test results. Insane Mode is enabled when launching a new Aviatrix Transit Gateway or Spoke gateway in GCP.
Support N2 and C2 instance types on GCP gateways improve Insane Mode (HPE) performance on GCP cloud. For new network throughput with these new instance types, refer to GCP Insane Mode Performance.
Automated and Policy-based service insertion and chaining have always been a real pain point for enterprise GCP customers. Native solutions are not adequate and 3rd party vendors’ solutions leave it up to the enterprise architect to figure out the end-to-end solution architecture.
Aviatrix GCP FireNet GCP solves all those challenges and limitations and provides a best practice way to Service Chain NGFW and other services into a cohesive architecture.
For this customer inspecting ingress traffic for GKE ingress controller traffic was a challenge for GKE workload based on their compliance policies. Following explains their ingress web traffic requirement
Route ingress traffic to a dedicated Ingress Spoke VPC first
Ingress VPC has an Nginx LB that would receive the traffic.
Then application LB policies were looked into and then based on the ingress service, the traffic must be routed to a centralized VPC where NGFW were deployed
Without Aviatrix, they were forced to terminate the ingress traffic directly to the NGFW which was not abiding by their Ingress traffic requirement. Also without Aviatrix, they were forced to figure out the routing and manually adjust the route based on a new service they would spin up.
Aviatrix FireNet policy-based and flexible model allows them to achieve the requirement with the traffic engineering demanded by the GKE workload
This provider processes a large number of image and video scans for their clients. The egress traffic sent to the clients after image/video processing was done must be secure and inspected by NGFW due to HIPPA compliance needs. They were forced to use Active/Standby NGFW due to various limitations.
Aviatrix FireNet solution allowed them to deploy the NGFW in an Active/Active fashion without involving any manual route updates or GCP network tag management. In case of failure Aviatrix FireNet automatically redirected traffic to the available NGFW. This reduced deployment complexity and manual intervention.
In the cloud era, the role of network security architect has become more critical than it has ever been. Complexity and human errors have always been the banes of security professionals. As enterprise cloud computing scales, it is expected to be 10x larger in size and complexity and will be deployed 1,000x faster than data center computing.
In this TechTalk, we focused on how enterprises are leveraging the Aviatrix cloud network platform to improve overall security posture, ensure corporate and regulatory compliance and embrace the exponential growth in enterprise cloud networking complexity by building on the combination of cloud security best practices and multi-cloud network architecture.
AWS VPC Ingress Routing allows customers to insert (or service chain) a security appliance/gateway or firewall for the traffic flows coming from the Internet and going towards the public-facing applications such as a web server. With Amazon VPC Ingress Routing, customers can define routing rules at the Internet Gateway (IGW) to redirect ingress traffic to third-party appliances, before it reaches the final destination.
Aviatrix takes full advantage of the Amazon VPC Ingress Routing Enhancement by combining it with
Aviatrix Security Gateway’s policy-based FQDN Filtering capabilities and
AWS GuardDuty is a threat and intrusion detection (IDS) service but it does not provide intrusion prevention (IPS) capabilities. The Aviatrix Controller programs an inline Aviatrix Security Gateway (called Public Subnet Filtering Gateway) to dynamically filter traffic to prevent unauthorized and malicious traffic.
Aviatrix Firewall Network Services (FireNet) simplify the Next Generation Firewall Insertion and Operations. FireNet is the simplest, highest performance, best scale-out architecture for next generation firewalls in the cloud.
Following are some of the highlights
Simple deployment, autoroute propagation to firewalls
Advanced egress, IDS, IPS, and ingress security
Maximize performance, scale, and visibility
Simplified – no IPSec tunneling or SNAT required
Integration with Check Point, Fortinet, and Palo Alto Networks Firewalls
FireNet for Google Cloud (GCP)
FireNet for GCP follows the same principle and provides the same benefits as in the other Cloud. It is the same architecture that is consistent across multiple clouds.
Like any other cloud GCP native networking and security services are different than AWS and Azure so there are some unique requirements that engineers should be aware of but from the design, deployment, and operations perspective it is transparent to the enterprise security and networking team.
Before we take a look at FireNet in GCP, we must understand the design requirement imposed by GCP that will lead us into the understanding it better later in the document.
GCP Networking Behavior
In this section, we will discuss the unique GCP Networking Behavior that will dictate some of the design choices needed to design a GCP FireNet solution
GCP Does Not Support Multiple Network Interfaces in the same VPC
GCP does not allow multi-NIC VMs to be deployed in the same VPC network. This restrictions forces Aviatrix FireNet customer to plan for additional VPCs as we will discuss later in the session
The GCP FireNet design is applicable to GCP Shared VPC or Standard VPC designs.
The GCP FireNet solution requires at least three interfaces to be deployed on the 3rd party security appliance or firewall. Some security vendors do allow Firewalls on stick design where there is only one NIC present to handle ingress, egress, east/west, and management traffic. This type of solution might be good for small deployment but poses scale and segmentation challenges in enterprise-grade security solutions.
Multi-NIC FireNet design is also more flexible and scalable and works really well with the GCP Shared VPC design.
This GW is deployed by Aviatrix controller with two interfaces.
NIC0 sits in Transit VPC (or Transit FireNet VPC). This side will be connected to Spoke GWs in their respective VPC
NIC1 connects to LAN VPC facing the Firewall
Firewall / Security Appliance VM
The Firewall is deployed by the Aviatrix Controller with 3 interfaces
NIC0 has the public IP address for the egress traffic. If egress traffic is not required, one can ignore it. The Controller will build this interface regardless
NIC1 is the management interface. Usually, a public IP address is assigned to this interface. In some cases, customers might want to access management via a private network (over Google Cloud Interconnect etc.) and can assign a private IP as well
NIC2 is connected to LAN VPC. This will be used to communicate with the Aviatrix Transit FireNet GW
Design Recommendations and Best Practices
Because VPC resource quotas are set at the project level, make sure to have aggregate VPC resource needs across all VPC
Do not deploy any workload in the Transit VPC
Do not deploy any workload in the LAN VPC
Do not deploy any workload in the Egress VPC
Aviatrix Transit FireNet Design with Standard GCP VPC
Following design shows Aviatrix Transit FireNet design with standard GCP VPC setup. This shows the Aviatrix Spokes also connected to Aviatrix Transit GW
Transit FireNet Deployment
[07:49:12] Starting to create GW aviatrix-transit-fnet-gw. [07:49:12] Connected to GCE. [07:49:14] Need gateway image. Copying now.. [07:53:28] Project check complete. [07:53:29] License check is complete. [07:53:53] Updating IGW for new gateway… [07:54:08] Launching compute instance in GCE…. [07:54:44] GCE compute instance created successfully. [07:54:44] Updating DB. [07:54:44] Added GW info to Database. [07:54:45] AVX SQS Queue created. [07:54:45] Initializing GW….. [07:55:02] Copy configuration to GW aviatrix-transit-fnet-gw done. [07:55:02] Copy new software to GW aviatrix-transit-fnet-gw done. [07:55:03] Copy misc new software to GW aviatrix-transit-fnet-gw done. [07:55:03] Copy scripts to GW aviatrix-transit-fnet-gw done. [07:55:03] Copy sdk to GW aviatrix-transit-fnet-gw done. [07:55:03] Copy libraries to GW aviatrix-transit-fnet-gw done. [07:55:03] Copy gateway system data files is done. [07:55:03] Installing software …. [07:55:07] Issuing certificates … [07:55:22] Issue certificates done [07:55:52] GW software started. [07:57:06] Software Installation done. [07:57:08] Run self diagnostics done. [07:57:11] Creating Firenet iLB [07:57:23] initializing security rule [07:57:24] GW security policy configured. [07:57:38] Enable FireNet function.
Kickstart deploys cloud and multi-cloud networks in minutes without any effort. Once the hub/spoke transit network is built in the cloud, it will act as a core networking layer on which one can add more use-cases as needed later.
The lightweight automation script deploys an Aviatrix controller and an Aviatrix transit architecture in AWS (and optionally in Azure). Everything is self-contained in a docker image. You do not need to install anything besides docker run time on your laptop/desktop/VM/instance.
This tool works the best for brand new Aviatrix Controller deployment
It is not recommended to launch the controller if one deployed already
If you have previously deployed Aviatrix Controller under the AWS account, you will receive the following errors. You need to manually remove those roles and policies before moving forward
Error: Error creating IAM Role aviatrix-role-ec2: EntityAlreadyExists: Role with name aviatrix-role-ec2 already exists.
Error: Error creating IAM Role aviatrix-role-app: EntityAlreadyExists: Role with name aviatrix-role-app already exists.
Error: Error creating IAM policy aviatrix-assume-role-policy: EntityAlreadyExists: A policy called aviatrix-assume-role-policy already exists. Duplicate names are not allowed.
Error: Error creating IAM policy aviatrix-app-policy: EntityAlreadyExists: A policy called aviatrix-app-policy already exists. Duplicate names are not allowed.
Before you start the deployment process, you need to do/have following
AWS accounts with root access
AWS Access Key ID
AWS Secret Access Key
AWS Keypair name (for the test EC2 instances) in the region (default region in standard mode is us-east-2) where you are planning to deploy the Spoke VPCs
Subscribe to Aviatrix Controller software in the AWS marketplace
Install Dockers and make sure Docker Desktop is running in your Mac / Linux or Windows Laptop, Desktop, VM, or EC2 during the deployment process
Run the following CLI commands on your laptop, desktop, VM, or EC2
% docker volume create TF
% docker run -v TF:/root -p 5000:5000 -d aviatrix/kickstart-gui
For checking the logs inside the container itself follow these steps
### Find the container process name using the docker ps commmand ###
shahzadali@shahzad-ali ~ % docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e773a53d34ca aviatrix/kickstart-gui "/bin/sh -c 'python3…" 17 hours ago Up 17 hours 0.0.0.0:5000->5000/tcp awesome_hofstadter
### To login to container istself use docker exec command ###
shahzadali@shahzad-ali /Users % docker exec -it awesome_hofstadter bash
### To check the docker logs without loggin into the container user docker logs command ###
shahzadali@shahzad-ali ~ % docker logs -f awesome_hofstadter
shahzadali@shahzad-ali ~ % docker logs -f awesome_hofstadter | more
[2021-01-11T22:13:32+0000] INFO __main__:24 Aviatrix kickstart has been started.
* Serving Flask app "app" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: on
[2021-01-11T22:13:32+0000] INFO werkzeug:113 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
[2021-01-11T22:13:32+0000] INFO werkzeug:113 * Restarting with stat
[2021-01-11T22:13:32+0000] INFO __main__:24 Aviatrix kickstart has been started.
[2021-01-11T22:13:32+0000] WARNING werkzeug:113 * Debugger is active!
[2021-01-11T22:13:32+0000] INFO werkzeug:113 * Debugger PIN: 320-893-258
[2021-01-11T22:13:50+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:50] "ESC[37mGET / HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:50+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:50] "ESC[37mGET /static/css/main.16b366d6.chunk.css HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:50+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:50] "ESC[37mGET /static/js/main.c622dd7f.chunk.js HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:50+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:50] "ESC[37mGET /static/js/2.746a07c0.chunk.js HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:50+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:50] "ESC[37mGET /static/media/Roboto-Regular.03523cf5.ttf HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:51+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:51] "ESC[37mGET /static/media/Roboto-Light.0cea3982.ttf HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:51+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:51] "ESC[37mGET /static/media/Roboto-Bold.4f39c579.ttf HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:51+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:51] "ESC[37mGET /api/v1.0/get-statestatus HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:51+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:51] "ESC[37mGET /static/media/Roboto-Medium.13a29228.ttf HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:51+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:51] "ESC[37mGET /favicon.ico HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:51+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:51] "ESC[37mGET /logo192.png HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:54+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:54] "ESC[37mPOST /api/v1.0/mode-selection HTTP/1.1ESC[0m" 200 -
[2021-01-11T22:13:54+0000] INFO werkzeug:113 172.17.0.1 - - [11/Jan/2021 22:13:54] "ESC[37mGET /api/v1.0/get-statestatus HTTP/1.1ESC[0m" 200 -
shahzadali@shahzad-ali ~ % docker logs -f awesome_hofstadter | tail
/root/kickstart_web.sh: line 743: export: `13.58.100.80': not a valid identifier
To delete the docker volume
To delete docker volume try following
shahzadali@shahzad-ali ~ % docker volume remove TF
Error response from daemon: remove TF: volume is in use - [4a75b428ff5badf368f1dc9761c51b903652d8cfa4da70b2bdd543be3d352fea, 7f54de5c900d28d23ea61965423394534fe40dd769b20ff78f3a31c1fa98987d]
shahzadali@shahzad-ali ~ %
If it gives you the error, then try following
shahzadali@shahzad-ali ~ % docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N] y
Deleted Containers:
7f54de5c900d28d23ea61965423394534fe40dd769b20ff78f3a31c1fa98987d
4a75b428ff5badf368f1dc9761c51b903652d8cfa4da70b2bdd543be3d352fea
c6de98c3284e8afdf5cff8f9b45266acf1e4bebf34a2ce0f7a20aa92342a43e5
6227ecf90cf4100b1a1391038171e8ae5dd0cff4f3a7007e4f675360396913da
An important security requirement for GCP VPCs is to effectively control remote user access in a policy based manner. The cloud and the COVID-19 pandemic makes most users “remote.” Not only for employees who are out of the office, the “remote” label can be applied to developers, contractors, and partners whether they’re in the office or around the globe.
Note: User VPN, Client VPN or OpenVPN are interchangeable terms.
Remote User VPN / Client VPN Overview
While a bastion host using an SSH tunnel is an easy way to encrypt network traffic and provide direct access, most companies looking for more robust networking will want to invest in a SMAL based VPN solution. Because …
Single instance VPN servers in each VPC results in tedious certificate management
No centralized enforcement give rise to questions like “who can access what VPC?”
With more than dozen users and more than a few VPCs, management and auditing of the user access can become a major challenge
What’s needed is an easily managed, secure, cost-effective solution. Aviatrix provides a cloud-native and feature-rich client VPN solution.
The solution is based on OpenVPN® and is compatible with all OpenVPN® clients
In addition, Aviatrix provides its own client that supports SAML authentication directly from the client
Each VPN user can be assigned to a profile with access privileges – down to hosts, protocols and ports
Any Identity provider auth for LDAP/AD, Duo, Okta, Centrify, MFA, Client SAML and other integrations
Centralized visibility of all users, connection history and all certificates across your network.
LAB Topology and Objective
This LAB is not dependent on any previous labs.
This LAB will build on the topology we have deployed already in the previous LABs. Following is what we have deployed already.
A GCP Spoke gateway (gcp-spoke-vpn) is already deployed in the gcp-spoke-vpn-vpc.
This is needed to make sure remote users, employees, developers or partners have a clear demarcation point (called Cloud Access layer in MCNA architecture) before they access the enterprise or corporate resources/workloads/VMs/etc.
Objective
Students will use their laptops to connect to this lap topology using an Aviatrix SAML client VPN and will become part of this topology. This will allow them to access any resources using the private IP address
Deploy Smart SAML Remote User VPN Solution
Deploy User VPN
Controller –> Gateway –> Create New (with the following information)
While creating this gateway, you must select “VPN Access” checkbox. This will make this gateway as OPENVPN Gateway for Aviatrix User VPN Solution
Common Mistake
The process could take upto ~10 minute to complete. It is hard to predict the deployment time even when you are deploying it in the same region and same cloud all the time.
Once the gateway is deployed, you can see the status and the GCP LB address that was created as part of the automation.
After the gateway deployment, the topology looks like following
GCP TCP LB Configuration (Reference Only)
Following screen shots show the TCP LB details in GCP that was created by Aviatrix automation. LB helps in scaling out the solution without any disruption to the user profile or certificates.
Notice: Students do not have access to this details. It is shared here fro reference purposes only.
Profile Based Zero-Trust Access Control
Each VPN user can be assigned to a profile that is defined by access privileges to network, host, protocol and ports. The access control is dynamically enforced when a VPN user connects to the public cloud via an Aviatrix VPN gateway.
Create a new profile: Controller –> OpenVPN –> Profile
Create a policy to allow users access to only VMs in gcp-spoke-vpc1.
Now add a remote uswr and assign profile to it. Make sure to provide correct email address here.
Add a New VPN User
Controller –> OPENVPN –> Add a New VPN User
Download the .ovpn profile file from the Aviatrix Controller
This should not ping because as per the zero-trust profile, the remote users are not allowed to access any resources expect in gcp-spoke-vpc-1
Ping the VM in the gcp-spoke-vpc-1
Most likely it will not ping because the “gcp-spoke-vpn” VPC is not assigned to any MCNS Domain yet
shahzadali@shahzad-ali ~ % ping 10.20.11.130
PING 10.20.11.130 (10.20.11.130): 56 data bytes
92 bytes from gcp-spoke-vpn.c.cne-pod24.internal (10.20.19.2): Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 7c18 0 0000 01 01 544d 192.168.19.6 10.20.11.130
Request timeout for icmp_seq 0
92 bytes from gcp-spoke-vpn.c.cne-pod24.internal (10.20.19.2): Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 b6da 0 0000 01 01 198b 192.168.19.6 10.20.11.130
Request timeout for icmp_seq 1
92 bytes from gcp-spoke-vpn.c.cne-pod24.internal (10.20.19.2): Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 fcc1 0 0000 01 01 d3a3 192.168.19.6 10.20.11.130
^C
--- 10.20.11.130 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
shahzadali@shahzad-ali ~ %
Now change MCNS setting and assign gcp-spoke-vpn to Green domain.
Now the new topology will look like following
Now connectivity is established and ping will start working as you can see in the following output as well.
Request timeout for icmp_seq 7
92 bytes from gcp-spoke-vpn.c.cne-pod24.internal (10.20.19.2): Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 2b8e 0 0000 01 01 a4d7 192.168.19.6 10.20.11.130
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
64 bytes from 10.20.11.130: icmp_seq=11 ttl=60 time=70.931 ms
64 bytes from 10.20.11.130: icmp_seq=12 ttl=60 time=63.498 ms
64 bytes from 10.20.11.130: icmp_seq=13 ttl=60 time=62.943 ms
64 bytes from 10.20.11.130: icmp_seq=14 ttl=60 time=69.129 ms
64 bytes from 10.20.11.130: icmp_seq=15 ttl=60 time=62.002 ms
64 bytes from 10.20.11.130: icmp_seq=16 ttl=60 time=68.655 ms
^C
--- 10.20.11.130 ping statistics ---
17 packets transmitted, 6 packets received, 64.7% packet loss
round-trip min/avg/max/stddev = 62.002/66.193/70.931/3.477 ms
shahzadali@shahzad-ali ~ %
Conclusion
Aviatrix User VPN is a powerful solution
MCNS provides additional security beyond the profile based user-vpn
ACE Enterprise in GCP wants to connect to different partners to consume SaaS services. These partners could be present in physical DC or Branches, or in VPC/VNET in the cloud such as GCP/AWS/Azure/etc. ACE cannot dictate or control the IPs/Subnets/CIDR those partners have configured and must support “Bring Your own IP” which might overlap with what is already configured in GCP.
In our topology GCP Spoke3 VPC subnet is overlapping with AWS Spoke2 VPC subnet (10.42.0.0). We need to make sure that VM in GCP Spoke3 VPC is able to communicate with EC2 in AWS Spoke2 VPC.
Topology Modifications
In order for this lab to work, we are simulating AWS Spoke2 VPC as a remote site/branch
Step#1: Detach the aws-spoke2 gateway from transit
Step#2: Delete the aws-spoke2-gw
Step#3: Deploy a standard Aviatrix Gateway (s2c-gw) in aws-spoke2-vpc
Controller –> Gateway –> Add New (use the following screen)
This getaway could be any router or firewall or vpn device in the on-prem or cloud location.
Topology
Following diagram shows the topology after the modifications are done
In the topology notice that there is no path between gcp-spoke3-vpc and s2c-gw in aws-spoke2-vpc
Also notice the local and remote virtual IPs allocated for the VPCs/Sites that are overlapping. This is needed so that these overlapping VPCs/Sites can communicate with each other using those virtual IPs
This is possible using Aviatrix patented technology where as a an enterprise you do not need to worry about programming advanced NAT rather Aviatrix intent based “Mapped NAT” policy will automatically take care of all the background VPC/VNET route programming, Gateway Routing, Secure Tunnel Creation, Certificate Exchange, SNAT, DNAT, etc.
Configuration
Bi-directional setup is needed for this to work. We will create two connections in coming configuration steps.
Connection From GCP to Partner Site (AWS) – Leg1
Controller –> SITE2CLOUD –> Add a new connection (with following details)
VPC ID / VNet Name: vpc-gcp-spoke-3 Connection Type: Mapped Connection Name: partner1-s2c-leg1 Remote Gateway Type: Aviatrix Tunnel Type: Policy-based Primary Cloud Gateway: gcp-spoke-3 Remote Gateway IP Address: Check Controller’s Gateway section to find the public ip address Remote Subnet (Real): 10.42.0.0/24 Remote Subnet (Virtual): 192.168.10.0/24 Local Subnet (Real): 10.42.0.0/24 Local Subnet (Virtual): 192.168.20.0/24
This will create the first leg of the connection from Cloud (GCP) to Partner Site (AWS). Tunnel will stay down until the other end is configured.
Download the Configuration
Aviatrix Controller provides a template that can be used to configure the remote router/firewall. Click on the Site-to-Cloud connection that you have just created. Click “EDIT” and then download the configuration for Aviatrix.
Now we need to create a new connection and import the file we just downloaded
Controller –> SITE2CLOUD –> Add a new connection –> Select “aws-west-2-spoke-2” VPC –> Import
VPC ID / VNet Name: aws-west-2-spoke-2 Connection Type: auto-populated (Mapped) Connection Name: partner1-s2c-leg2 Remote Gateway Type: Aviatrix Tunnel Type: auto-populated (Policy-based) Algorithms: auto-populated (do not change these settings) Primary Cloud Gateway: auto-populated (aws-spoke2-vpc-s2c-gw) Remote Gateway IP Address: auto-populated Remote Subnet (Real): auto-populated (10.42.0.0/24) Remote Subnet (Virtual): auto-populated (192.168.20.0/24) Local Subnet (Real): auto-populated (10.42.0.0/24) Local Subnet (Virtual): auto-populated (192.168.10.0/24)
Now it will take about a minute for both tunnels to come up
This makes is look like following
Verification
Now you can ping the overlapping subnet VM on the AWS side from GCP. Make sure to use the virtual subnet for AWS with the last octet of the VM being the same.
ubuntu@vm-gcp-spoke-3:~$ ifconfig
ens4 Link encap:Ethernet HWaddr 42:01:0a:2a:00:82
inet addr:10.42.0.130 Bcast:10.42.0.130 Mask:255.255.255.255
inet6 addr: fe80::4001:aff:fe2a:82/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:1492666 errors:0 dropped:0 overruns:0 frame:0
TX packets:871540 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:518583431 (518.5 MB) TX bytes:111566034 (111.5 MB)
ubuntu@vm-gcp-spoke-3:~$ ping 192.168.10.84
PING 192.168.10.84 (192.168.10.84) 56(84) bytes of data.
64 bytes from 192.168.10.84: icmp_seq=1 ttl=62 time=83.8 ms
64 bytes from 192.168.10.84: icmp_seq=2 ttl=62 time=83.5 ms
64 bytes from 192.168.10.84: icmp_seq=3 ttl=62 time=83.6 ms
64 bytes from 192.168.10.84: icmp_seq=4 ttl=62 time=83.6 ms
64 bytes from 192.168.10.84: icmp_seq=5 ttl=62 time=84.2 ms
^C
--- 192.168.10.84 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 83.554/83.784/84.203/0.391 ms
ubuntu@vm-gcp-spoke-3:~$
This concludes the lab. Final topology looks like following
