Notes:
This document is based on Aviatrix version 6.0
Site = A physical branch and/or data center
Cloud = Public cloud (Azure/AWS/GCP/OCI)Aviatrix provides physical branch (or DC) to cloud connectivity using various mechanisms. This document first explains the IPSec technologies and then their Aviatrix implementation details.
Policy Based VPN (aka Native IPSec)
- This type of VPN is used for both Site-2-Cloud and User remote access VPN (User VPN).
- Simpler to create
-
IPSec tunnel is specified within the policy itself with an action of “IPSec”
-
Only one policy is required
-
Used in Aviatrix standalone S2C GW worklflow
-
Difficult to troubleshoot
Route Based VPN
- Mainly used to build Site-to-Cloud (Hub-Spoke) VPN IPSec connection
- Route Based VPN can use GRE with IPSec or VTI with IPSec
- Aviatrix implementation uses VTI (virtual tunnel interface) with IPSec
- Route Based VPN are more flexible, more powerful and recommended over policy based VPNs
- A route based VPN is created with two policies, one for inbound and another for outbound with a normal “Accept” action
- A static route is also required for a route based VPN
- Any traffic destined to the remote network must go through the virtual IPSec interface which was created when specifying this within the Phase 1 settings
-
Typically used where the VPN connection requires redundancy
- Used by Aviatrix Transit Gateway, CoudWAN and ActiveMesh workflows
- This is the industry standard now. All major vendors recommend to use this method
- In 6.0 AVX TR GW is always route-based (BGP or static), and always be
- In 6.0, we can choose (step 3) the remote side to either use BGP, or static route-based
- static remote route-based --> means the IOS-generated config. will be route-based for on-prem
IPSec VPN Type Quick Comparison
Aviatrix IPSec Features Based on Gateway Types
Aviatrix can build the IPSec tunnel mainly from two types of gateways. The availability of features varies based on the type of gateway and use-cases. Over time it will improve and we will have feature parity
Aviatrix Standalone Site-2-Cloud Gateway (S2C)
Usually customers deploy S2C standalone gateway with policy-based VPN
Route-based VPN - Static
This is a new feature in 6.0 which now allows a route-based (VTI) on-prem device to connect o Aviarix-S2C-GW in the Cloud.
Caveat: Supports IKEv1 only as of 6.0 (enabling IKEv2 will result in following error)
Policy-based VPN
IKEv1 and IKEv2 supported (as you can see in the following diagram)
Note: 0.0.0.0/0 is not allowed in the "Remote Subnet" option
Aviatrix Transit Gateway
Usually customers deploy route-based VPN with Aviatrix Transit GWs. Aviatrix Transit Gateway only support IKEv1 as of version 6.0. Aviatrix Transit Gateway can build different types of tunnel with the destination based on the workflow being used.
Starting from release 6.0, Aviatrix ActiveMesh Transit Gateway supports both remote route based VPN and remote policy based VPN tunnels. In both cases, the Aviatrix Transit Gateway operates in route based mode. Note if the remote site is policy based static VPN, traffic must be initiated from the remote site.
Route-based VPN - BGP
This is most widely used and recommended option used with Aviatrix Transit GW. This can only be configured from the Aviatrix Multi-Cloud transit workflow.
Route-based VPN - Static
This mode only support IKEv1 as of 6.0 release.
Aviatrix Transit Policy-based VPN using S2C Workflow
When you configure VPN to remote sites from Site2Cloud page and select a Transit GW, the VPN tunnel is built with policy based VPN.
If the remote site is policy based static VPN, traffic must be initiated from the remote site.
As mentioned earlier as well, the Aviatrix Transit GW does not support IKEv2 as of version 6.0
This is the new feature in Aviatrix 6.0 release. Now customers can connect Aviatrix Transit Gateway with external devices such as routers and firewalls using policy-based VPN.
This is an important feature that provides interop between a route-based Aviatrix Transit GW and a remote policy-based IPSec tunnel destination. This use-case is to allow the remote site to participate in the ActiveMesh 2.0 route selection in a unified manner.