Deploy Use-Cases and Experience Aviatrix Platform - Test Plan
After building the Aviatrix Sandbox Starter environment, it is highly recommended to first deploy Aviatrix CoPilot and follow the instructions to experience advanced visibility and monitoring capabilities.
Even if you don't deploy CoPilot, here are a few test cases to familiarize yourself with the platform.
You may also refer to https://docs.aviatrix.com to deploy use-cases beyond to what is discussed here in this post.
Once you are signed in, if you chose to build the Transit in AWS as well as in Azure, your Controller dashboard will look like this:
To verify that everything is working like it should, go on the menu on the left and click “Accounts”, and then “Access Accounts”.
End-to-end Verification from Test Instances
You should be able to perform an end-to-end ping from one Test instance to the other using the Private IP address.
SSH to workloads using the following example, make sure you are in the directory where the key pair is stored.
$ chmod 400 <your-key.pem> $ ssh -i “<your-key.pem>” ec2-user@<test-instance-publicIPAddress>
Multi-Cloud Transit List of Transit Gateways
In the UI, go to MULTI-CLOUD TRANSIT > List > Transit tab. If you built both the AWS and the Azure Transits and left the names, regions, and VPC/VNet CIDRs as default, then you should receive a screen similar to this:
Multi-Cloud Transit List of Spoke Gateways
In the UI, go to MULTI-CLOUD TRANSIT > List > Spokes tab. If you built both the AWS and the Azure Transits and left the names, regions, and VPC/VNet CIDRs as default, then you should receive a screen similar to this:
End-to-end Verification from FlightPath
From the Controller, go to TROUBLESHOOT > FlightPath and run a series of end-to-end test from one Test instance to the other using their Private IP addresses. Note that the Test instances have a prefix of Spoke. Run the following tests:
- ICMP – This should succeed
- SSH (TCP 22) – This should succeed
- HTTPS (TCP 443) – This should fail because a Security Group denies it
Sample results from the HTTPS test are shown below:
Navigate to TROUBLESHOOT > Diagnostics > Network tab. From any Gateway, perform an ICMP test. For example, if you have the default environment, from AZ-EU-Spoke1-GW, issue a Ping to www.aviatrix.com. You should receive output such as this:
Network Connectivity Utility
Navigate to TROUBLESHOOT > Diagnostics > Network tab. In the Hostname field, enter the IP address of a test instance, protocol TCP, and port 22. Pick an AWS Gateway (either Spoke or Transit). You should receive a screen similar to this:
Navigate to TROUBLESHOOT > Diagnostics > Packet Capture to perform a packet capture. This shows a capture taken while SSH was attempted on one of the test instances:
Navigate to TROUBLESHOOT > Diagnostics > Network Validation to select the Source and Destination Account, Region, and Network to perform a connectivity test in AWS. The Aviatrix Controller will spin up two instances and run a connectivity test. You can leave these instances running or delete them when you’re done. You should receive a screen similar to this:
Deployment and Provisioning
Go to USEFUL TOOLS > VPC Tracker If you built both the AWS and the Azure Transits and left the names, regions, and VPC/VNet CIDRs as default, then you should receive a screen similar to this:
Notice the following:
This list of VPCs is pulled from all the accounts you have onboarded. If you have a new AWS account, then typically you have a default VPC with default 172.31.0.0/16 CIDR subnet in a few regions as per AWS documentation.
Enter a few CIDRs in the text field at the top and hit Test. Deliberately pick a CIDR that already exists. For example, if you have the default environment and test the availability of 10.62.0.0/16, you should receive a screen similar to this:
If you have the default environment and test the availability of 10.63.0.0/16, you should receive a screen similar to this:
Create a VPC
After verifying that the Network CIDR does not overlap anywhere in your network, create a new VPC directly from the Controller.
Note: The Destroy button in the top right corner of Sandbox Starter Tool will only destroy resources that it created. If you manually create a resource such as a VPC from the Controller UI, you are responsible for its lifecycle and charges incurred.
To create a VPC, navigate to USEFUL TOOLS > Create a VPC
Secure Egress Traffic - FQDN Filter
Note: This test will require creating additional resources from the Controller UI. You are responsible for their lifecycle and the charges incurred. The charges will be about $0.02 an hour if you choose AWS t2.micro instances.
In this lab, you can test the Egress FQDN feature, an inexpensive replacement for an AWS NAT Gateway that can filter Internet-bound egress traffic initiated from workloads in a VPC. This service is centrally managed by the Aviatrix Controller and executed by an Aviatrix gateway instance in the VPC in a distributed architecture.
This adds one test instance and one Aviatrix Gateway to the architecture as shown in the red oval here:
To perform this test, follow these steps:
- The Aviatrix Controller already builds a few private subnets. Pick one and from the AWS Console, create a t2.micro test instance in Spoke1-VPC in that private subnet. Make sure Auto-assign Public IP is set to Disable. Give it a name such as AWS-UE2-Egress-FQDN-test. Ensure that its Security Group allows all traffic.
- From the Aviatrix Controller, deploy a Gateway in Spoke1-VPC as follows:
Navigate to GATEWAY > + CREATE NEW
Create a Gateway in AWS-UE2-Spoke1-VPC-Public-0-us-east-2a Public Subnet in AWS-UE2-Spoke1-VPC as shown here:
Since the Egress FQDN test VM has no Public IP, you will need to use one of the other test VMs as a jump box (i.e. bastion host). Also copy the private SSH key to the ~/.ssh directory and then SSH to the Private IP. For example,
[ec2-user@ip-10-61-53-107 ~]$ chmod 400 .ssh/acelab.pem [ec2-user@ip-10-61-53-107 ~]$ ssh -i .ssh/acelab.pem firstname.lastname@example.org Last login: Sat May 22 21:12:59 2021 from ip-10-61-53-107.us-east-2.compute.internal __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ [ec2-user@ip-10-61-0-199 ~]$
Once you are on the Egress FQDN test VM, issue a few Egress FQDN actions:
[ec2-user@ip-10-61-0-199 ~]$ curl google.com ^C [ec2-user@ip-10-61-0-199 ~]$ sudo yum update -y Loaded plugins: extras_suggestions, langpacks, priorities, update-motd Could not retrieve mirrorlist https://amazonlinux-2-repos-us-east-2.s3.us-east-2.amazonaws.com/2/core/latest/x86_64/mirror.list error was 12: Timeout on https://amazonlinux-2-repos-us-east-2.s3.us-east-2.amazonaws.com/2/core/latest/x86_64/mirror.list: (28, 'Connection timed out after 5000 milliseconds') One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=<repoid> ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable <repoid> or subscription-manager repos --disable=<repoid> 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true Cannot find a valid baseurl for repo: amzn2-core/2/x86_64 [ec2-user@ip-10-61-0-199 ~]$
Notice that this test instance, which is in a Private Subnet, has no way to communicate externally. Therefore, all Egress traffic fails.
Enable Egress FQDN Discovery. Navigate to SECURITY > Egress Control > 2 (Optional) Egress FQDN Discovery. Enable the Egress FQDN Gateway you created in this section from the Controller UI as shown in here:
Now try issuing those same Egress FQDN commands again.
[ec2-user@ip-10-61-0-199 ~]$ curl google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="http://www.google.com/">here</A>. </BODY></HTML> [ec2-user@ip-10-61-0-199 ~]$ sudo yum update -y Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 amzn2extra-docker | 3.0 kB 00:00:00 (1/5): amzn2-core/2/x86_64/group_gz | 2.5 kB 00:00:00 (2/5): amzn2-core/2/x86_64/updateinfo | 367 kB 00:00:00 (3/5): amzn2extra-docker/2/x86_64/updateinfo | 76 B 00:00:00 (4/5): amzn2extra-docker/2/x86_64/primary_db | 78 kB 00:00:00 (5/5): amzn2-core/2/x86_64/primary_db | 52 MB 00:00:01 No packages marked for update [ec2-user@ip-10-61-0-199 ~]$
The new Aviatrix Gateway allows all outbound traffic and you can see domains that were reached above:
Click on the Download button to download the results, then Stop Egress FQDN Discovery, and enable Egress FQDN Filter that permits HTTP traffic to google.com and HTTPS traffic to the amazonaws.com domain that is needed for AWS yum updates. To do so, navigate to SECURITY > Egress Control > 3 Egress FQDN Filter > + New Tag and give the Tag a name, such as SST-Tag, shown here:
Next, edit this tag and add new filters based on the discovery results, such shown below. Click Import to upload the results file. Then click on Update to Save.
These two filters will match HTTPS (TCP 443) traffic to amazonlinux-2-repos-us-east-2.s3.us-east-2.amazonaws.com and HTTP (TCP 80) traffic to google.com. However, you will not be able to access facebook.com over HTTP/HTTPS or ping google.com. You can add new rules with wildcards.
Set the Tag to White List, attach it to the Egress FQDN gateway, and ensure that the Tag is Enabled so that the configuration resembles this:
Now, the same Egress actions result in the following:
[ec2-user@ip-10-61-0-199 ~]$ curl google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="http://www.google.com/">here</A>. </BODY></HTML> [ec2-user@ip-10-61-0-199 ~]$ sudo yum update -y Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 No packages marked for update [ec2-user@ip-10-61-0-199 ~]$ curl facebook.com ^C [ec2-user@ip-10-61-0-199 ~]$ ping google.com PING google.com (220.127.116.11) 56(84) bytes of data. ^C --- google.com ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 5113ms [ec2-user@ip-10-61-0-199 ~]$
As you can see, there are fine controls for Egress Traffic based on FQDNs.
If you have any questions about Aviatrix Sandbox Starter Tool, don't hesitate to contact us at email@example.com.
In the VPC Tracker section of the 'Test Plan' example, the following is stated:
This list of VPCs is pulled from all the accounts you have onboarded. If you have a new AWS account, then typically you have a default VPC with default 172.31.0.0/16 CIDR subnet in a few regions.
I notice the VPC Tracker 'Screen shot' lists (for example) 10.61.0.0/16 CIDR that appears to be 'owned' by an account called 'aws-account'. therefore the question I have is:
1 - Is 'aws-account' a new account as it has a 10.61.0.0/16 CIDR and also a 172.31.0.0/16 CIDR?
Additionally - I notice that the VPC Tracker 'Screen shot' appears to show that these 172.31.0.0/16 CIDR have no 'instances', so - the question I have is:
2 - Does this mean Aviatrix has 'onboarded' a VPC that had no Spoke Gateways configured for the VPC?
Secure Egress Traffic - FQDN Filter
While following the steps in this exercise I have noticed that the accompanying screenshots make reference to subnet 10.61.64.0/20 as being allocated to region eu-west (Ireland). However CIDR 10.61.0.0/16 is allocated to US East 2 (Ohio). I've looked at the 3 subnets listed for eu-west1 (Ireland) under my AWS account and these are all 172.31.x.x /20
Can you confirm:
Should the example - showing the gateway being deployed in eu-west1 (Ireland) - be ignored and I just pick another region/cloud of my choice?
If - I have mis-read or mis-understood the steps, could you please clarify, what region/cloud/subnet in the FQDN filter test plan can be used for this deployment.
While you're there - Step 3 of the 'Egress FQDN' test plan states to do the following:
[ec2-user@ip-10-61-29-14 ~]$ ping google.com
PING google.com (18.104.22.168) 56(84) bytes of data.
--- google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3052ms
My question is:
What AWS instance do I action these steps from? - as:
1 - I have no access to the Spoke1-VM or Spoke2-VM (I have no keys/passwords to these instances)
2 - Creation of the 'Egress-FQDN-test' instance stated to create 'Egress-FQDN-test' without a public address (is there a 'back door' to this instance via it's private address?)
If there is somewhere on the forum site that holds the keys/passwords, can you please advise or maybe I have mis-understood what I need to do?
Currently - the way I view things is that I have no way of being able to use any of these instances without creating another instance, with a public address, and use that as a 'jump-off server'.