@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.
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.
Looking at the architecture diagram, we want to access the hqnetworksrv PostgreSQL Server from HQ-Network VNET, the Applications 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.
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.
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:
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.
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.
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:
In Create a private endpoint - Resource, enter or select this information:
In Virtual Network enter this information:
Note: Use the predefined private DNS zone for your service or provide your preferred DNS zone name.
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.
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:
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:
If you are going to your VNG-HQ-Network page you can already see traffic over the tunnel ingress and egress.
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.
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 : 184.108.40.206 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.
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.
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.
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.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.