1. Base policy of a tag can either be Allow or Deny, it cannot be both
2. 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.
3. 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.
4. 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
5. Only HTTP/HTTPs traffic support wildcard FQDN (eg: *.domain.com). None HTTP/HTTPs traffic requires specific FQDN (eg: custom.protocol.domain.com)
6. 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.
7. If a match of deny rule was applied, no further tags will be processed.

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.

As of writing, on Aviatrix Controller version 7.1.2131 and CoPilot v4.3.1, the current process of installing a certificate:

1. 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. 
2. 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.