- 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 FQDN Egress (legacy) design considerations
Reply