How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 2

@StephenFoerster mentioned in Connecting Viya in Azure to On-Prem with Azure VPN, ExpressRoute (Intro): “Microsoft recommends two different mechanisms for connecting SAS Viya in Azure to on-premises resources […] Both methods require Azure Virtual Network (VNET) gateways to facilitate communication. Site to Site VPN connections also require VPN devices configured on premises.”

Read this post to learn how you can connect a SAS Viya on Azure deployment to an on-premises network by using site-to-site VPN gateways. When the connection is in place, you can access from SAS Viya resources from your on-premises data centre, for example, a database.

Context and Objective

The previous post, How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 1:

Introduced site-to-site VPN gateway connections.
Simulated an on-premises data centre in Azure, to which we want to connect from SAS Viya.
Provided the Azure CLI commands to create:
- Gateway subnets for each virtual network (VNET) you want to connect with Virtual Network Gateways.
- Local Network Gateways.

Architecture Diagram

As a reminder, by the end of the post series, we want to realize the following architecture diagram:

To reiterate the objective, we want to connect to the on-premises database from SAS Viya, through the VPN tunnel.

Assumptions

SAS Viya deployed on Azure, in the $PREFIX-vnet mentioned in the diagram.
You created the resources mentioned in How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 1.

Create the Azure-side VPN gateway

First, you'll create the VPN gateway for the Azure end of the connection. It can take up to 45 minutes to create a virtual network gateway. To save time, you can use Azure CLI commands with the --no-wait parameter to minimize the overall time required. This parameter lets you create both virtual network gateways simultaneously.

Public IP for the Virtual Network Gateway

The VPN gateway must be associated with a public IP. Create the PIP-VNG-$PREFIX-VNet public IP address.

az network public-ip create \
    --resource-group $RG \
    --name PIP-VNG-${PREFIX}-vnet \
    --allocation-method Dynamic

Virtual Network Gateway

Create the VNG-$PREFIX-VNet virtual network gateway.

az network vnet-gateway create \
    --resource-group $RG \
    --name VNG-${PREFIX}-vnet \
    --public-ip-addresses PIP-VNG-${PREFIX}-vnet \
    --vnet ${PREFIX}-vnet \
    --gateway-type Vpn \
    --vpn-type RouteBased \
    --sku VpnGw1 \
    --no-wait

Note: you need to create a route-based gateway. Route-based VPNs use "routes" in the IP forwarding or routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the tunnels.

Create the On-premises VPN gateway

Next, you'll create a VPN gateway in HQ-Network to simulate an on-premises VPN device.

Public IP for the Virtual Network Gateway

Create the PIP-VNG-HQ-Network public IP address.

az network public-ip create \
    --resource-group $RGHQ  \
    --name PIP-VNG-HQ-Network \
    --allocation-method Dynamic

Virtual Network Gateway

Create the VNG-HQ-Network virtual network gateway

az network vnet-gateway create \
    --resource-group $RGHQ \
    --name VNG-HQ-Network \
    --public-ip-addresses PIP-VNG-HQ-Network \
    --vnet HQ-Network \
    --gateway-type Vpn \
    --vpn-type RouteBased \
    --sku VpnGw1 \
    --no-wait

Monitor the Creation

Gateway creation takes approximately 45 minutes to complete. Run the command to check whether both virtual network gateways have been created.

az network vnet-gateway list \
    --resource-group $RG  \
    --output table
az network vnet-gateway list \
    --resource-group $RGHQ  \
    --output table

The initial state will show Updating. You want to see Succeeded on both VNGs.

After each VPN gateway shows a ProvisioningState of Succeeded, you're ready to continue.

When Both Virtual Network Gateways Have Been Created

The local network gateway IP must be updated to reflect the virtual network gateway IP from the vnet we want to connect to.

Effectively, you are “crossing” the IP addresses:

The IP address of the VNG-HQ-Network from the HQ-Network is assigned to the LNG-HQ-Network from $PREFIX-vnet.
The IP address of the VNG-$PREFIX-vnet from $PREFIX-vnet is assigned to the LNG-$PREFIX-vnet from HQ-Network.

Update the Azure Local Network Gateway IP

Retrieve the IPv4 address assigned to PIP-VNG-HQ-Network and store it in a variable.

PIPVNGAZUREVNET=$(az network public-ip show \
    --resource-group $RGHQ \
    --name PIP-VNG-HQ-Network \
    --query "[ipAddress]" \
    --output tsv)
echo $PIPVNGAZUREVNET

Update the LNG-HQ-Network local network gateway so that it points to the public IP address attached to the VNG-$PREFIX-VNet virtual network gateway.

az network local-gateway update \
    --resource-group $RG \
    --name LNG-HQ-Network \
    --gateway-ip-address $PIPVNGAZUREVNET

Update the On-premises Local Network Gateway IP

Retrieve the IPv4 address assigned to PIP-$PREFIX-VNet and store it in a variable.

PIPVNGHQNETWORK=$(az network public-ip show \
    --resource-group $RG \
    --name PIP-VNG-${PREFIX}-vnet \
    --query "[ipAddress]" \
    --output tsv)
echo $PIPVNGHQNETWORK

Update the LNG-$PREFIX-VNet local network gateway so that it points to the public IP address attached to the VNG-$PREFIX-VNet virtual network gateway.

az network local-gateway update \
    --resource-group $RGHQ \
    --name LNG-${PREFIX}-vnet \
    --gateway-ip-address $PIPVNGHQNETWORK

Create the Connections

You'll now complete the configuration by creating the connections from each VPN gateway to the pair local network gateway.

Shared Key

Create the shared key to use for the connections. In the following command, replace with a text string to use for the IPSec pre-shared key. The pre-shared key is a string of printable ASCII characters no longer than 128 characters. It can't contain special characters, like hyphens and tildes. You'll use this pre-shared key on both connections.

SHAREDKEY=1A2b3C4D5e6^7%8

In this example, any set of numbers will work for a shared key. In production environments, we recommend using a string no longer than 128 characters.

IKE: Internet Key Exchange (IKE) is a standard protocol used to set up a secure and authenticated communication channel between two parties via a virtual private network (VPN). The protocol ensures security for VPN negotiation, remote host and network access.

IPSec: IKE is a part of IPsec, a suite of protocols and algorithms used to secure sensitive data transmitted across a network. The Internet Engineering Task Force (IETF) developed IPsec to provide security through authentication and encryption of IP network packets and secure VPNs.

Create the First Connection

Create a connection from VNG-$PREFIX-VNet to LNG-HQ-Network.

az network vpn-connection create \
    --resource-group $RG \
    --name ${PREFIX}-vnet-To-HQ-Network \
    --vnet-gateway1 VNG-${PREFIX}-vnet \
    --shared-key $SHAREDKEY \
    --local-gateway2 LNG-HQ-Network

Create the Second Connection

Create a connection from VNG-HQ-Network to LNG-$PREFIX-VNet.

az network vpn-connection create \
    --resource-group $RGHQ \
    --name HQ-Network-To-${PREFIX}-vnet \
    --vnet-gateway1 VNG-HQ-Network \
    --shared-key $SHAREDKEY \
    --local-gateway2 LNG-${PREFIX}-vnet

LNG-$PREFIX-VNet contains a reference to the public IP address associated with the VNG-$PREFIX-VNet VPN gateway. This connection would normally be created from your on-premises device.

You've now finished the configuration of the site-to-site connection. This will take a few minutes, but the tunnels should automatically connect and become active.

Verify the Connections

Let's confirm that the VPN tunnels are connected.

az network vpn-connection show \
    --resource-group $RG     \
    --name ${PREFIX}-vnet-To-HQ-Network \
    --output table \
    --query '{Name:name,ConnectionStatus:connectionStatus}'

az network vpn-connection show \
    --resource-group $RGHQ     \
    --name HQ-Network-To-${PREFIX}-vnet   \
    --output table \
    --query '{Name:name,ConnectionStatus:connectionStatus}'

You shall see:

bt_3_Site-to-Site-VPN-VNET-Connection-VNG-e1683164395128.png

Conclusions

The site-to-site VPN tunnel is now complete.

Virtual network gateways were created in Azure and "on-premises" (in the simulated data centre).
The local network gateway IP was updated to reflect the virtual network gateway IP from the VNET we want to connect to.
Site-to-site VPN gateway connection was configured. VPN connections have been successfully established.
Resources in SAS Viya subnets $PREFIX-misc-subnet and $PREFIX-aks-subnet can now access resources from the Applications subnet.

Read the next post, How to Connect SAS Viya in Azure to On-Prem with VPN Gateways - Part 3, where you will learn how to test the access to the on-premises database from SAS Viya and verify the traffic over the VPN tunnel.

Useful Resources

Thank you for your time reading this post. If you liked the post, give it a thumbs up! Please comment and tell us what you think about access to on-premises datacentres using VPN gateways. If you wish to get more information, please write me an email.