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.
UI Walkthrough
Dashboard
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: 
Access Accounts
To verify that everything is working like it should, go on the menu on the left and click “Accounts”, and then “Access Accounts”.
Confirm that the Account Number or ID are accurate, which can be found here for AWS and here for Azure.
Operations
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:
Gateway Utility
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:
Packet Capture
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:
Network Validation
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
VPC Tracker
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,
eec2-user@ip-10-61-53-107 ~]$ chmod 400 .ssh/acelab.pem
-ec2-user@ip-10-61-53-107 ~]$ ssh -i .ssh/acelab.pem ec2-user@10.61.0.199
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:gec2-user@ip-10-61-0-199 ~]$ curl google.com
^C
eec2-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.
Eec2-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>
oec2-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
rec2-user@ip-10-61-0-199 ~]$ curl facebook.com
^C
nec2-user@ip-10-61-0-199 ~]$ ping google.com
PING google.com (142.250.191.174) 56(84) bytes of data.
^C
--- google.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5113ms
aec2-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 kickstart@aviatrix.com.