- Base policy of a tag can either be Allow or Deny, it cannot be both
- When base policy is allow:
- tag entries using base policy will be allowed
- tag entries using explicit allow will be allowed,
- tag entries using explicit deny will be dropped
- Any other FQDN not in the tag entries will be dropped.
- When base policy is deny:
- tag entries using base policy will be dropped.
- tag entries using explicit deny would be dropped
- tag entries using explicit allow will be allowed.
- Any other FQDN not in the tag entries will be allowed.
- When multiple tags are associated with the same FQDN gateway, they must all have same type of Base policy
- either all tags base policy use Allow
- or all tags base policy use Deny
- Only HTTP/HTTPs traffic support wildcard FQDN (eg: *.domain.com). None HTTP/HTTPs traffic requires specific FQDN (eg: custom.protocol.domain.com)
- When there are multiple tags associated with same FQDN gateways, for example:
- Tag 1 edit source option not been used
- Tag 2 edit source option not been used
- Tag 3 edit source option used and linked to source CIDR: 10.16.64.0/24
- When 10.16.64.4 initiate egress traffic, Tag 3 will be applied first, as it matches more specific source CIDR range 10.16.64.0/24. Then less specific tags, such as Tag 1 and Tag 2 (not necessary the order listed in GUI) will be applied.
- Aviatrix controller will program the order of Tag1 and Tag2, you will have to engage Aviatrix Support to find out the exact sequence programmed on FQDN gateway.
- If a match of deny rule was applied, no further tags will be processed.
Aviatrix Azure Marketplace offer
CloudShell CLI
CLI format:
az vm image terms accept --urn publisher:offer:sku:version
To accept Aviatrix Controller Marketplace offer:
az vm image terms accept --urn aviatrix-systems:aviatrix-bundle-payg:aviatrix-enterprise-bundle-byol:latest
To accept Aviatrix CoPilot Marketplace offer:
az vm image terms accept --urn aviatrix-systems:aviatrix-copilot:avx-cplt-byol-01:latest
To validate, replace ‘accept’ with ‘show’ and rerun the command, it should say:
"accepted": true,
To cancel the offer:
az vm image terms cancel --urn aviatrix-systems:aviatrix-bundle-payg:aviatrix-enterprise-bundle-byol:latest
az vm image terms cancel --urn aviatrix-systems:aviatrix-copilot:avx-cplt-byol-01:latest
PowerShell code
To accept Aviatrix Controller Marketplace offer:
Set-AzMarketplaceTerms -Publisher aviatrix-systems -Product aviatrix-bundle-payg -Name aviatrix-enterprise-bundle-byol -Accept
To accept Aviatrix CoPilot Marketplace offer:
Set-AzMarketplaceTerms -Publisher aviatrix-systems -Product aviatrix-copilot -Name avx-cplt-byol-01 -Accept
To validate:
Get-AzMarketplaceTerms -Publisher aviatrix-systems -Product aviatrix-bundle-payg -Name aviatrix-enterprise-bundle-byol -OfferType 'virtualmachine'
Get-AzMarketplaceTerms -Publisher aviatrix-systems -Product aviatrix-copilot -Name avx-cplt-byol-01 -OfferType 'virtualmachine'
To cancel the offer:
Stop-AzMarketplaceTerms -Publisher aviatrix-systems -Product aviatrix-bundle-payg -Name aviatrix-enterprise-bundle-byol
Stop-AzMarketplaceTerms -Publisher aviatrix-systems -Product aviatrix-copilot -Name avx-cplt-byol-01
Terraform code
# Accept Aviatrix Controller market place agreement
resource "azurerm_marketplace_agreement" "aviatrix_controller" {
publisher = "aviatrix-systems"
offer = "aviatrix-bundle-payg"
plan = "aviatrix-enterprise-bundle-byol"
}
# Accept Aviatrix CoPilot market place agreement
resource "azurerm_marketplace_agreement" "aviatrix_copilot" {
publisher = "aviatrix-systems"
offer = "aviatrix-copilot"
plan = "avx-cplt-byol-01"
}
Publisher, Offer, Sku data source
Aviatrix Publishes these information in JSON file:
Controller: https://cdn.prod.sre.aviatrix.com/image-details/arm_controller_image_details.json
CoPilot: https://cdn.prod.sre.aviatrix.com/image-details/arm_copilot_image_details.json
Aviatrix Source NAT (SNAT) on BGP Spoke
Aviatrix customer has applications running in various VPCs, these applications need to be able to communicate with FiServ securely via BGP over IPSec tunnels. FiServ also has lots of its own customers that most likely use RFC1918 as internal address space. To avoid conflicts, FiServ assigns non-RFC1918 IP Prefixes to FiServ customers, the incoming connection must be Source NAT (SNAT) to these non-RFC1918 IP Prefixes, and FiServ also only allows incoming traffic from these non-RFC1918 IP Prefixes on FiServ firewalls.
FiServ reference architecture: https://developer.fiserv.com/product/FirstVisionEMEA/docs/?path=docs/Support/Client-Onboarding.md&branch=main#connectivity-overview-diagram
This blog intends to walk through various considerations that affects final design.
Continue readingRequest/Renew SSL Certificate for Aviatrix Controller/CoPilot
As of writing, on Aviatrix Controller version 7.1.2131 and CoPilot v4.3.1, the current process of installing a certificate:
- For Aviatrix Controller
- By default, the Aviatrix Controller uses a self-signed certificate. In this case, an option to generate a Certificate Signing Request (CSR) will be available. The CSR requires the Fully Qualified Domain Name (FQDN) of the controller, e.g., avx-controller.mycompany.com. When the CSR is generated, the controller will also generate and store a corresponding private key. The generated CSR is supplied to the Certificate Authority (CA) which will return a signed public certificate. In addition to this certificate, a CA certificate (generally publicly available from the CA) will also be required during the import process.
- If a public certificate is already installed, you can no longer generate a CSR without first reverting to a self-signed certificate.
- There is also an option to import an externally generated private key with corresponding public and CA certs.
- For Aviatrix CoPilot
- The Copilot does not support the generation of CSR’s. Instead, an externally generated private key and corresponding CA-signed public key are required for importation.
The processes above can be challenging for customers, especially when renewing existing certificates. This confusion is compounded by the variety of different certificate types of Certification Authorities, certificate formats and operating system tools.
This blog intends to create a more standardized process for Aviatrix Customers to follow.
Continue readingPicking the correct subnet from Aviatrix created VPC
Resource aviatrix_vpc creates a VPC/vNet/VCN in various cloud types. For Aviatrix Transit VPC, there would be various different subnets created for the purpose of integrating with SDWan appliances, insertion of Firewalls, integration with AWS TGW (Aviatrix Orchestrated), or utilizing AWS Gateway Load Balancer etc.
An example of subnets created in AWS for Aviatrix Transit VPC with High-Performance Encryption, TGW-O integration, and Firewall integration with GWLB.
Continue readingRun a script in MAC from the dock
I have recently moved from Windows 11 to MacOS 14.0.
In Windows 11, I had several scripts written in PowerShell or Python. For each script, a shortcut was created, an icon assigned, then the shortcut was pinned to the start menu for quick access.
It took me a while to figure out similar ways in Mac.
Continue readingGain Visibility and Control of your AWS Public Subnet Workloads
It is common for enterprise customers to run a workload in AWS in a public-facing subnet, where the default route (0.0.0.0/0) would be pointing to the AWS internet gateway (IGW). Reference: AWS Internet Gateway Documentation
The IGW provides NAT between the public IP and the private IP assigned to the instance. You may control inbound/outbound traffic via Security Group, where you can control what protocol and IP range that would have access. However, IGW won’t provide you much visibility of the traffic going in/out from your instance, and you may need to use FlowLogs to gain some level of visibility. Some examples of FlowLogs can be found here: Flow log record examples. You may find it lack of detail and very difficult to read.
For enterprise customers that value visibility and security, as well as simplified IT operations, Aviatrix has designed a Public Subnet Filtering gateway feature for AWS public subnet workload.
Continue readingSimply method to log connectivity and have asymmetric in mind
When helping customer migrate to Aviatrix, most of the time, we have standard migration process, which is documented here. Few customer may need customized migration architecture due to their existing architecture and special requirements. These customized migration architecture require additional testing to understand what would be the potential impact to traffic flow. While most enterprise customer may have monitoring system in place, but in the lab/dev/QA phrase, we may not have the luxury to have full fledge monitoring system deployed. In this blog post, I will show you a simple method to log connectivity between desired data paths without breaking a sweat or the bank.
Continue readingImport existing resources into CloudFormation template
Aviatrix developed Migration Toolkit to help customer migrate from existing AWS/ Azure environment to Aviatrix Transit and Spoke Multi-Cloud Networking Architecture (MCNA). I have discussed the process in blog: Migrate from Azure vNet hub and spoke architecture to Aviatrix Transit. The AWS migration process is similar, where the toolkit make copies of existing route tables, when Aviatrix Spoke is attached to Aviatrix Transit, we are using these copied route tables, hence no traffic interruption would happen. During the traffic switching phrase, subnets will be associated with the copied route table, and in TGW we disable the migrating VPC router advertisement, so the traffic would swing over to Aviatrix Spoke/Transit.
Some of our customers are using CloudFormation to manage the deployment of their environment, while Aviatrix Controller will handle bulk of the work such as populating RFC1918 and/or default route in the route table and/or non-RFC1918 routes from External connections, they still would like to have the ability to continue to use CloudFormation to manage endpoint routes. This created a split brain scenario, how do we handle this?
Continue readingAviatrix CoPilot Baseline Metric
Enterprise customers values Aviatrix CoPilot for track and gather evidential data on their network. The platform aggregates abundant Syslog and Netflow data, which can be used to establish baseline metrics for alerting. Customers can choose to modify or add/remove metrics to suit their specific needs. Here is a list of recommended baseline metric, as well as detail of each one’s meaning.
Continue reading