Aviatrix supports policy-based and route-based VPNs and those can be configured on standalone, spoke, and transit gateways.
The workflow for configuration can be found at https://docs.aviatrix.com/HowTos/site2cloud.html.
The focus of this blog are designs where the VPN is deployed on its own spoke or using spoke gateways or a combination of standalone and spoke gateways as described later on. Those configurations are done using the SITE2CLOUD menu:
One-to-one mapping is supported: the Remote and Local Subnet fields can contain multiple values comma separated.
The maximum number of CIDRs for Site2Cloud network maps is 32.
If the Local Subnet field is outside the gateway VPC/VNet, you need manually grant access to the gateway changing the inbound security rules.
If you select the Custom Mapped checkbox after selecting the Mapped option, more complex Site2Cloud configurations are possible.
The lab I’ll use is sketched below:
Standalone Gateways using Single IP HA
Single IP HA is supported on standalone gateways and only can be configured during the s2c creation:
The IP that will be used is the public IP of the primary gateway:
S2C Configuration
On-prem configuration
Testing
Fail over
Public ip is moved from the primary gateway to the secondary (hagw):
Without any tuning the entire fail over took 4:20 min (fail over depends heavily on Azure API):
Tuning
Tuning the keep alive and detection time saved a few seconds (fail over time 4:09 min).
Scale in and Scale out
The design can provide more capacity (# of connections, throughput) changing the size of the gateway and or add more gateways.
Active/Standby Spoke Gateway
S2C Configuration
Auto advertise spoke Site2Clouds CIDRs injects 172.31.10.0/24 into BGP and propagates towards the spokes:
- Transit:
- Spoke:
On-Prem Configuration
Testing
Fail over
I shutdown the active gateway to force a fail over which based on the logs took 3:50 minutes to converge. The ping ran from the on-prem across the spoke30 – transit- spoke40:
23:19:19.238671 IP az-east-us-spoke40-useg-vm1.internal.cloudapp.net > 172.31.10.1: ICMP echo reply, id 132, seq 2564, length 8023:23:09.347896 IP az-east-us-spoke40-useg-vm1.internal.cloudapp.net > 172.31.10.1: ICMP echo reply, id 132, seq 2680, length 80Scale In and Scale Out
The design can provide more capacity (# of connections, throughput) changing the size of the gateway and or add more gateways.
One thought on “Providing Scalability and Availability for Site-2-Cloud VPN with Overlapping IP addresses”