On-Premise point-to-site connectivity leveraging Logic Apps Integration Services Environment (ISE) in a Hub-Spoke network topology

Today Microsoft made the Logic Apps Integration Services Environment (ISE) available to the broader public by announcing its Public Preview!

Whilst ISE was in private preview I was able to battle test it and my initial findings proofed it to be resilient, reliable and above all performant. This of course is to be expected as the ISE environment is a completely isolated environment which uses dedicated storage and other resources and as such the days are gone of having to share an environment with a noisy neighbour ūüėä

Specifically the ISE environment is a real good fit for all those scenario’s in which one requires access to secured resources, systems and/or services in an Azure Virtual Network.

But before I start repeating all the pros/cons and other goodness regarding the why, I can only recommend that you give the following well written documents a go.

Note; if you are merely interested in the configuration details which allows to connect your ISE to your on-premise hosted systems using a Hub-Spoke network topology, scroll down…

Background

Whilst I was battle testing the ISE environment there was one specific scenario I was curious about if it was supported. This scenario consists of leveraging multiple subscriptions within the same tenant whilst having one dedicated ‘core’ subscription containing the core virtual network components such as the virtual network gateway, this kind of networking architecture is typically referred to as a¬† Hub and Spoke VNET architecture.

So what makes this scenario so unique to be tested out, you might ask? Well in order to be able to establish a secure connection to your on-premise network we will have to rely on a VPN Gateway (Azure virtual network gateway) and within our Hub and Spoke network topology this would mean that our ISE environment would live in a different Azure Subscription, leveraging its own Virtual Network, which as such requires additional configuration (VNET Peering).  Nothing really fancy you might reckon, well not really, as previously we ran into issues where we were not able to connect to an on-premise hosted system leveraging a dedicated Azure Functions App living outside of the core subscription and which was connected to the core subscription containing the VNET which had the VPN Gateway.

Anyways long story short; the above scenario works with ISE and as such I would easily recommend using the Hub-Spoke networking topology in combination with ISE as this architecture offers the following benefits (Blatantly copied from Hub and Spoke VNET architecture):

  • Cost savings¬†by centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location.
  • Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

And is a perfect fit for scenario’s such as:

  • Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Shared services are placed in the hub VNet, while each environment is deployed to a spoke to maintain isolation.
  • Workloads that do not require connectivity to each other, but require access to shared services.
  • Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

So enough blabla, let’s dig into the nitty gritty; let’s get to it.¬†

How-to: Allowing On-Premise point-to-site connectivity leveraging Logic Apps Integration Services Environment (ISE) in a Hub-Spoke network topology

Note; I will be describing the high-level configuration but will include links to articles hosted on the Microsoft Docs site, containing the specifics around configuration and other required steps in more details.

 The image below depicts the high-level infrastructure configuration as I have tested.

In the above picture we see a simplified model of the Hub and spoke network topology in which I tested my ISE environment. The solution relies on two Azure subscriptions (both leveraging the same tenant).

Subscription A

 utilises the main HUB VNET (VNET Y) and contains my shared services, including the VPN gateway which is responsible for establishing secure tunnels to my work laptop which hosts a sample REST API and my home server which hosts a FTP server. VNET Y contains 3 subnets configured as mentioned below

Subnet Address Range Available Addresses
DMZ Subnet 10.1.0.0/29 3
Workload Subnet 10.1.1.0/24 250
VPN Gateway Subnet 10.1.0.16/28 10

More information on how to configure a VNET including the VPN Gateway for point-2-site connectivity can be found by clicking on the following link:

Subscription B

is used to host my core integration services and contains a separate VNET (VNET X) in which I’ve deployed the ISE. VNET X contains 4 subnets as required when setting up a ISE and which are configured as mentioned below

Subnet Address Range Available Addresses
ISE Subnet 1 10.1.3.0/27 27
ISE Subnet 2 10.1.3.32/27 27
ISE Subnet 3 10.1.3.64/27 27
ISE Subnet 4 10.1.3.96/27 27

More information on how to set up an ISE including the subnet requirements can be found by clicking on the following link:

VNET Peering

In order for ISE to talk to my ‘on-premise’ servers it needs to connect to the VPN gateway, hosted in Subscription A. This is achieved by means of leveraging VNET peering and ensuring that both peering for VNET Y and VNET X are configured as depicted in the table below.

 Peering Direction Allow  forwarded traffic Allow gateway traffic Use remote gateways
VNET Y (Hub) Core to ISE False (Unchecked) True (Checked) False (Unchecked)
VNET X (Spoke) ISE to Core True (Checked) False (Unchecked) True (Checked)

More information on how to configure VNET peering and allow traffic to use the VPN gateway can be found by clicking on the following link:

 Testing on-prem connectivity

At this point you should have all the information needed to successfully create a Hub-spoke VNET topology, create a VPN point-2-site VPN, enable VNET peering and provisioned an ISE; and more importantly you should have done so in the following order:

  1. Provisioned and configured a VNET in your ‘core’ subscription, containing multiple subnets
  2. Provisioned and configured a point-2-site VPN using the Azure VPN Gateway Service
  3. Provisioned and configured a VNET in your ‘integration’ subscription, containing at least 4 subnets
  4. Provisioned and configured an Integration Service Environment in your ‘integration’ subscription
  5. Set up VNET peering on your VNET in your ‘core’ subscription and in your ‘integration’ subscription.
  6. Established point-2-site VPN connections from your on-premise servers to your VNET in your ‘core’ subscription.

In order to validate that your ISE can successfully communicate with your ‘on-premise’ hosted servers, you would need to create some Logic Apps within the ISE which would leverage ISE compatible connectors. At the point of writing this blogpost the following connectors are ISE compatible and are able to leverage all the goodness contained within your (linked) VNETs

  • Azure Blob Storage, File Storage, and Table Storage
  • Azure Queues, Azure Service Bus, Azure Event Hubs, and IBM MQ
  • FTP and SFTP-SSH
  • SQL Server, SQL Data Warehouse, Azure Cosmos DB
  • AS2, X12, and EDIFACT

Additionally built-in triggers and actions such as HTTP always run in the same ISE as your logic app and are as such capable to  leverage all the goodness contained within your (linked) VNETs as well.

Test: Calling on-premise hosted REST-API

The screenshot depicted below details the basic ISE hosted logic app which I created to test my on-premise connectivity, leveraging the HTTP connector. Please note; the IP used ūüėČ

Designer view
Execution run view

Test: Calling on-premise hosted FTP-Server

The screenshot depicted below details the basic ISE hosted logic app which I created to test my on-premise connectivity, levering the FTP (ISE) Connector. Please note; the IP used¬† ūüėȬ† for the FTP API connection

FTP Connection view

Execution run view

Conclusion

Although a lengthy blog-post with quite some links to external Microsoft links; it proves pretty straightforward to configure your Azure Environment such that you can have your ISE environment connect to your ‘on-premise’ hosted systems / services. Taking into account that ISE has full VNET support even complex networking topologies such as the Hub and spoke architecture are supported.

Cheers

René

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *