Accessing a Virtual IP Address Instance via Aviatrix Transit Network

This document addresses the scenario where a customer on-prem firewall device needs to route encrypted traffic to a partner network in the cloud (AWS/Azure/GCP), but due to concerns for overlapping CIDR blocks to the customer network, the customer side enforces a policy that the destination IP address must be a public or a virtual IP address regardless of whether the partner network is in the RFC 1918 range.

For example, the VPC instance IP address that the on-prem machine should send data to is 172.123.4.5, but the on-prem machine must instead send data to a virtual IP address 54.189.117.94 (or even 100.100.100.100).

Normally this problem can be solved by combining the Site2Cloud feature and DNAT feature.

There are situations where there are multiple applications in different VPCs, and it is desirable to access different virtual addresses without building multiple IPSEC tunnels to the cloud networks. This can be accomplished by building an Aviatrix Transit Network where Spoke VPCs host these different applications, as shown in the diagram below.