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

@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 test the connection from SAS Viya on Azure to an on-premises database over site-to-site VPN gateways.

Context and Objective

The previous posts, How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 1 and How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 2 explained how to create a site-to-site VPN gateway connection to a simulated on-premises data centre. We simulated the data centre as an Azure network, for pure convenience.

In this post, we will deploy a PostgreSQL server in the "on-premises" network and we will connect to it from SAS Viya. We will also look at the traffic over the Virtual Network Gateways.

Architecture Diagram

Looking at the architecture diagram, we want to access the hqnetworksrv PostgreSQL Server from HQ-Network VNET, the Applications subnet:

First, from SAS Viya deployed in the $PREFIX-vnet, the $PREFIX-aks-subnet.
Second, from a Virtual Machine deployed in the $PREFIX-vnet, the $PREFIX-misc-subnet.

The data access will happen over the established VPN tunnel. The VPN tunnel allows for encrypted network traffic over the public Internet, between an Azure virtual network and on-premises data centres.

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 and How to Connect SAS Viya in Azure to On-Prem with VPN Gateways – Part 2.

Optional: Enable Network Watcher - VPN Troubleshoot

Network Watcher has a useful tool, called the VPN troubleshoot. You can use it to diagnose VPN connections between networks.

Enable VPN Troubleshoot. You will need a storage account. Later, after you generated some traffic over the VPN tunnel, you can check later the logs in the storage account.

Deploy "On-premises" Resources

Deploy a PostgreSQL Server

The simulated data center is an Azure Database for PostgreSQL server in Azure.

On the upper-left side of the screen in the Azure portal, select Create a resource > Databases > Azure Database for PostgreSQL.

In Azure Database for PostgreSQL deployment option, select Single server and provide this information:

Subscription – select your subscription.
Resource group – HQ-rg. You created the resource group earlier.

Server details:

Server name: hqnetworksrv .
Admin username: Enter viyadep .
Password: the password must be at least 8 characters long and meet the defined requirements.
Location: East US.
Version: Select the required database version of the PostgreSQL server.
Compute + Storage: Select the pricing tier needed for the server based on the workload: General Purpose.
Select OK.

Select Review + create. You're taken to the Review + create page where Azure validates your configuration. When you see the Validation passed message, select Create. The server must be deployed before you proceed any further.

bt_3_PostgreSQLServer_Simulated_On_Premises_Data_Center-e1683168593757-214x300.png

What are Azure Private Endpoints?

Let's stop for a minute and introduce a new concept, the Azure Private Endpoint.

Azure Private Endpoints: What Are They and What Are Their Use Cases? explains them as: “a powerful tool that allow you to securely access your Azure services over a private endpoint. With Private Endpoints, you can connect to Azure services without exposing your data to the public internet, improving security and compliance for your applications.

Azure Private Endpoints are commonly used in scenarios where customers want to access Azure services from a private network, such as an on-premises network or a virtual network in Azure. In these scenarios, customers can use Private Endpoints to connect to Azure services over a private connection without having to expose their data to the public internet.”

In Azure they can be used for an entire range of services. Read more about it here.

Deploy a Private Endpoint for your PostgreSQL Server

In our case, the purpose of a private endpoint is to allow clients to securely access data over a Private Link. Clients can be: SAS Viya or a VM deployed in an Azure virtual network (VNet).

The private endpoint uses a separate IP address from the VNet address space for each service, like the PostgreSQL server database.

Network traffic between SAS Viya, and the PostgreSQL server will traverse over the VNet and a private link on the Microsoft backbone network, eliminating exposure from the public internet.

On the upper-left side of the screen in the Azure portal, select Create a resource > Networking > Private Link.

In Private Link Center - Overview, on the option to Build a private connection to a service, select Create a private endpoint.

In Create a private endpoint - Basics, enter or select this information:

Project details:

Subscription: Select your subscription.
Resource group: Select your "on-premises" resource group, HQ-rg.

Instance Details:

Name Enter hqnetworkPE. If this name is taken, create a unique name.
Region: East US.

In Create a private endpoint - Resource, enter or select this information:

Connection method: Choose Connect to an Azure resource in my directory.
Subscription: Select your subscription.
Resource type: Microsoft.DBforPostgreSQL/servers.
Resource: hqnetworksrv . This is the PostgreSQL server you deployed earlier.
Target sub-resource: postgresqlServer.

In Virtual Network enter this information:

Virtual network: HQ-Network .
Subnet: Applications.
Dynamically allocate IP addresses.

In DNS:

Integrate with private DNS zone, select Yes.
Private DNS Zone: choose the default: e.g. (new)privatelink.postgres.database.azure.com .

Note: Use the predefined private DNS zone for your service or provide your preferred DNS zone name.

bt_5_Azure-Deploy-a-Private-Endpoint-for-PostgreSQL-3.png

Retrieve the Private IP Address

When the Private Link has been created, Go to Resource and from DNS configuration, get the private IP address generated, for example: 172.16.0.4.

Deny Public Network Access

When we access the PostgreSQL server from SAS Viya, we want to stay away from the public internet.

We want to force the database traffic via the private link, over the VNet and on the Microsoft backbone network. To force the traffic, disable the public network access for PostgreSQL Server:

Test the Connection to the “On-premises” Database from SAS Viya

In SAS Studio, write the following SAS code. The SAS server becomes the private IP address of the PostgreSQL Server (private endpoint). Connect to the default postgres database:

libname GELDBHQ clear;
libname GELDBHQ postgres server='172.16.0.4' port=5432
   user='viyadep@hqnetworksrv' password='fill_in_here'
   database=postgres SSLMODE='prefer';

Connection is successful, and you can access the database:

bt_8_SAS_Viya_Studio_Test_Access_On_Prem_DB-1024x371.png

Virtual Network Gateway Traffic

If you are going to your VNG-HQ-Network page you can already see traffic over the tunnel ingress and egress.

bt_9_Site-to-Site-VPN-Connection-VNG-HQ-Network-traffic.png

The traffic in the VPN tunnel was generated by the traffic between SAS Viya and the PostgreSQL server database.

Egress in the world of networking implies traffic that exits an entity or a network boundary, while ingress is traffic that enters the boundary of a network.

Network Watcher VPN Troubleshoot: Proof Packets are Sent over the VPN Tunnel

The Network Watcher VPN Troubleshoot will send data to a storage account of your choice. Check the storage account after you access the database from SAS Studio.

Connectivity State : Connected
Remote Tunnel Endpoint : 74.235.4.188
Ingress Bytes (since last connected) : 128412 B
Egress Bytes (since last connected) : 31889 B
Ingress Packets (since last connected) : 383 Packets
Egress Packets (since last connected) : 360 Packets
Ingress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Egress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Bandwidth : 0 b/s
Peak Bandwidth : 0 b/s
Connected Since : 5/2/2023 8:33:49 AM
PeakPackets : 0
TotalFlowCount : 0
Throttle : False

The relevant part is in the first six lines, the ingress or egress bytes and packets, proving data travels through the VPN tunnel.

Conclusions

You can access the data from SAS Viya over a VPN tunnel. The traffic travels VNET-to-VNET (Virtual Network Gateway to Local Network Gateway) in an encrypted fashion.

There are advantages of using Azure gateways and site-to-site connections. You do not need to whitelist the SAS Viya Load Balancer Public IP on the PostgreSQL server side. Nor do you require an inbound rule in the SAS Viya AKS Network Security Group for the PostgreSQL Server IP or the port 5432 (PostgreSQL).

In addition, we deployed a private endpoint and denied public access to "force" the PostgreSQL server traffic to stay inside the network and only travel through the VPN tunnel, the site-to-site connection.

SAS customers can use private endpoints for their Azure services and access data from SAS Viya. The traffic will flow over the Microsoft backbone. Private endpoints are even more relevant when you peer the SAS Viya network with other networks in Azure.

ExpressRoute

Read the next post, How to Connect SAS Viya in Azure to On-Prem with ExpressRoute – Part 1, where you will learn how to take connectivity to a next level.

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.