Author: Vikas Parikh

Configure virtual network in Azure

Prerequisite for this tutorial is that you have configured Azure like below:

Learn how to configure the above virtual network in Azure by exploring my YouTube video: Azure P2S connectivity with DNS

Create a VPC

List of VPCs created will look something like below:

Here, we have 1 VPC already created, which is called – appfolio-vpc 

Pay special attention to the following configuration of VPC:

The below is configured at the time of creating the VPC. You can learn more about this process here.

Region, CIDR, and environment for the created environment will look similar to the following:

  1. Region: US West (N. California)
  • Region to which Anypoint VPC is bound.
  • All apps deployed to this region under the business group configured in #4 will be deployed to this Anypoint VPC
  1. CIDR block: 10.0.0.0/16
  • Size the VPC in CIDR notation
  • CIDR block comes from private IP space and it should be unique amongst (a) Other address space of your VPC and (b) address space of the corporate network (on-prem to which you are establishing the IPSEc VPN tunnel, in our case, it will be Azure)
  • CIDR blocks once assigned to VPC, can’t be edited.
  • Make sure to size it properly, here is a guidance 
  1. Environments: Sandbox
  • Environment which is bound to your VPC.
  • You can have multiple environments bound to your single VPC
  1. Business Groups: Apisero Sandbox
  • Bind your Anypoint business group with the VPC
  • Business group for the created environment look like below:
  1. Firewall Rules: Default
  • Configure firewall rules. Default rules will be pre-populated
  • One can edit the rules at any time
  • Firewall rules for the created environment look like below:
  1. Internal DNS
  • Here, we need to configure the (a) DNS server ips and (b) corporate resources domain (parent level domain) that we need to resolve
  • Note that domain is not he DNS server domain
  • We are going to explore this at depth at a later point in this tutorial
  • DNS can be configured at any point. Once changed, we need to restart the apps deployed to your VPC.
  • Internal DNS for the created VPC look like below:

Deploy the test application in VPC

  • Deploy the vpn-db-test application in your VPC. 
  • Find the test application source below:
  • The test app tries to connect to your DB server of the Azure and lists all the employees
  • Application is very lightweight and looks like below:
  • Deploy the application in Runtime Manager in your VPC cloudhub region like below:
  • Logs suggest that DB server name is not resolved, check below:
  • Reason being: DB server is not accessible from internet and VPN tunnel is not established for VPC yet
  • We will create a VPN and revisit this step to check if connectivity to on-prem DB server can be established

Create a VPN

  • Go to Runtime Manager → Sandbox (target environment) → VPNs
  • Click button – Create VPN
  • Fill the form to create an IPSec VPN Tunnel with Azure as highlighted below:
  • Name: ipsec-vpn-tunnel-azure
  • VPC: appfolio-vpc (select your VPC from dropdown)
  • Remote IP Address: 40.121.153.70 

Public IP Address of the Azure Virtual Network Gateway

  • Routing Type: Static 

We have configured static routing in our Azure network

  • Static Routes: 10.1.0.0/16, 10.2.0.0/16

These are the address spaces of the your Azure virtual network

These are NOT the address space of your subnets

  • Local ASN: 64512

Keep the default

  • Tunnel Configuration: Automatic
  • Hit the button – Create VPN
  • Upon creation, VPN gets listed with below statuses

VPN Status: PENDING

Tunnel 1: PENDING

Tunnel 2: PENDING

Status are depicted in VPN list page as highlighted below:

  • Let’s wait for VPN to change it’s status from PENDING to AVAILABLE

Tunnel status will remain DOWN till Azure is configured with tunnel configuration

Click the VPN when status changes to AVAILABLE as highlighted here 

  • 2 tunnel configurations (highlighted here) are to be utilized to configure other side of the tunnel in Azure

Configure the other side of the tunnel in Azure

  • Create an Azure Local network gateway (representing remote tunnel # 0 endpoint) as highlighted here

Configure below:

  1. Name: remote-mule-endpoint-0
  2. IP Address: 54.67.95.61 (Local external IP Address of VPN Tunnel #0)
  3. Address Space: 10.0.0.0/16 (CIDR block of the VPC)
  • Similarly configure Local network gateway # remote-mule-endpoint-1
  • Local network gateways look like below:
  • Now, let’s configure the connections within Virtual Network Gateway that was earlier created, as highlighted below:
  • Click Add connection and configure as below as shown here

Name: azure-mule-tunnel-0

Connection Type: S2S (Site-to-site)

Virtual network gateway: Auto selected, previously created

Local network gateway: remote-mule-endpoint-0

PSK: PSK of VPN Tunnel # 0

IKE Protocol: IKEv2

Hit OK button

Creating connection takes a while

  • Similarly, create another connection # azure-mule-tunnel-1 for tunnel #1
  • Both the connections are highlighted below:
  • Wait till the time, both the connection status become Connected
  • Once connected, check the MuleSoft VPN IPSec Tunnel status
  • Both Tunnel 1 and Tunnel 2 statuses should be UP as highlighted below:
  • This should conclude VPN tunnel configuration
  • Tunnel is configured at both the end and available for data transfer

Revisit the test application

  • Re-deploy the vpn-db-test application in your VPC
  • And check the result in logs
  • Logs suggest that DB server name is still not resolved, check below:
  • Reason being: Even though VPN tunnels are established, names of on-prem resources are not resolved.
  • To have name resolution, we need to configure the Azure DNS server (configured as part of pre-requisite) in the MuleSoft VPC as highlighted below:
  • Once saved, redeploy the vpn-db-test
  • Logs look clean now, check below:
  • When application is hit through REST endpoint, employees (as configured in the Azure DB server) are fetched and transformed, as highlighted below:
  • This concludes VPN tunnel configuration and name resolution to connect to on-prem resources

Leave a Comment