Introduction
The design and deployment discussed in this blog will walk us through how to navigate an end-to-end cloud network and demonstrate remote user access to the cloud resources in different connected VPCs via Aviatrix VPN. We will also demonstrate how to manage access controls from a user profile while connected to VPN (by default, a user when connected to Aviatrix VPN can reach all connected cloud resources).
In addition, we will also demonstrate the deployment of SAML-based authentication with Azure AD IdP by configuring SAML-based authentication between Aviatrix and Azure AD.
Pre-Requisites
- Already deployed Aviatrix Controller Controller Startup Guide.
- Azure AD Premium subscription account with administrator access.
- Install Aviatrix VPN client.
Configuration
Step 1
Please follow Steps 1 to 4 of this blog for SAML integration with Azure AD.
Note:- This endpoint will be under the OpenVPN section of the Aviatrix Controller as shown in the below screenshot.
Step 2
Launch Aviatrix Gateway with VPN access and SAML.
Aviatrix Controller > Gateway > Launch Gateway > Enable VPN access and SAML
Step 3
Create VPN users
Aviatrix Controller > OpenVPN > VPN Users > Add > Enable SAML Endpoint created in Step 1 above. Optionally we can add a Profile to users which we will later use for access control.
In the below screenshot, we demonstrate a VPN profile enabled on VPN users.
Step 4
Load the certificate from VPN user to Aviatrix VPN client (you should receive it in an email when you created VPN gateway or you could download it as shown here)
Load the downloaded certificate on the Aviatrix VPN client as shown in the below screenshot.
Step 5
Once VPN user is connected via Aviatrix VPN client. Based on configuration on Step 1, the user will be authenticated by Azure AD and we would be able to see VPN users logged in our controller dashboard.
Validation
Let's understand User VPN connectivity to our cloud environment via Aviatrix VPN gateway and VPN client with the help of the topology diagram below
US-WEST-1
Transit VPC with CIDR 10.10.0.0/16 (Transit Gateway IP 10.10.0.84)
Spoke VPC 1 with CIDR 10.11.0.0/16 (Spoke Gateway IP 10.11.34.62 and EC2 instance IP 10.11.44.255)
Spoke VPC 2 with CIDR 10.12.0.0/16 (Spoke Gateway IP 10.12.40.199)
Both Spoke VPCs are attached to Transit VPC.
US-EAST-2
Spoke Gateway 172.16.5.85 attached to Transit VPC in US-WEST-1
VPN gateway (172.16.5.90) deployed in US-EAST-2
Aviatrix Controller and CoPilot deployed in US-EAST-2
Now, when a user is connected to Aviatrix VPN client (authenticated by Azure AD IdP), which is installed in local machine. The local machine should be able to reach cloud resources in different VPCs shown in the topology diagram.
From the local machine, you should be able to ping VPN Gateway, Spoke Gateways, Transit Gateway, EC2 instance, or any application deployed in it (as long as the user is connected to the Aviatrix VPN client).
Bold green lines in topology resemble user VPN traffic for remote users.
We can define Max number of active VPN connections allowed to be connected to the VPN gateway, enable client certificate sharing so one .ovpn file can be shared with multiple/all VPN users. We can also leverage Split tunnel and Full tunnel modes to control the CIDRs reachability for User VPN.
Split Tunnel - only traffic that is destined to the VPC/VNet CIDR where the VPN gateway is deployed is going into the VPN tunnel when a user is connected to the VPN gateway.
Full Tunnel - all laptop traffic, including Internet traffic, is going through the VPN tunnel when a user is connected to the VPN gateway.
Aviatrix Controller > OpenVPN > Edit config
Access Control
Aviatrix supports Policy-based access control through which each VPN user can be assigned to a profile which when enabled with appropriate policies controls the user access privileges to network, host, port, or protocol.
Let's understand this by modifying our topology such that the user connected to Aviatrix VPN has been attached to a profile that denies accessibility to Spoke VPC 2 (10.12.40.199). This is shown by the bold red line in the topology diagram below.
Profile and policies from the Aviatrix controller are shown in the below screenshot.
We are demonstrating a policy that denies ICMP traffic from a remote user under VPN PROFILE to Spoke VPC 2 (10.12.40.199).
After applying the policy shown above, our local machine should reach all the networks except 10.12.40.199 as shown in the topology diagram above.
The access control is dynamically enforced when a VPN user connects to the public cloud via an Aviatrix VPN gateway.
Multi-Cloud access for remote user
The beauty of the Aviatrix Platform is that it works seamlessly across multiple clouds and the remote users will be able to connect to multi-cloud resources once deployed in the Aviatrix VPN solution and we have transit connectivity across clouds.
Let's demonstrate this by modifying our topology and deploying Azure as shown below
As per our topology design, we have transit connectivity from our transit VPC in AWS to our transit VNET in Azure. Once a user connects to our VPN gateway using the Aviatrix VPN client, it should have connectivity to transit and spoke VNET in azure as well as any resources deployed in it.
US-EAST
Transit VNET with CIDR 10.20.0.0/16 (Transit Gateway IP 10.20.0.4)
Spoke VNET 1 with CIDR 10.21.0.0/16 (Spoke Gateway IP 10.21.0.4)
Spoke VNET 2 with CIDR 10.22.0.0/16 (Spoke Gateway IP 10.22.0.4)
