Loading...

How to allow traffic from Internet to a Cloud Service Extended Support with Internal Load Balancer

How to allow traffic from Internet to a Cloud Service Extended Support with Internal Load Balancer

The previous article explained how user could configure and limit the access to Cloud Service Extended Support (CSES) only from specific Virtual Network(s) by using internal Load Balancer feature. But for some scenarios, user does not really want to fully block the traffic from public Internet, but just wants to make the CSES safer. In this scenario, adding an Azure Application Gateway in front of CSES will be a good idea. It can provide following benefits:

  • From public Internet, the traffic is only able to reach CSES through Application Gateway
  • From Virtual Network, the traffic is not blocked by this design
  • User can add additional feature such as Web Application Firewall to make the traffic safer

 

Generally speaking, Azure Application Gateway is an OSI layer 7 service. It can be used for load balancing, WAF and some other purposes. For more details about this service, please check here.

 

 

Pre-requirement:

You need to follow this document at first and have a running CSES with internal Load Balancer. The following screenshots are from my environment (Frontend IP using 10.0.3.200, a private IP address, proving it’s an internal Load Balancer):

CSES Internal LB frontend IPCSES Internal LB frontend IP

CSES Internal LB backend poolCSES Internal LB backend pool

CSES Internal LB health probeCSES Internal LB health probe

CSES Internal LB load balancing ruleCSES Internal LB load balancing rule

 

 

The traffic design

CSES with internal LB + App Gateway traffic flowCSES with internal LB + App Gateway traffic flow

As above diagram, the part inside of yellow dash is in Virtual Network. The outside part of yellow dash is the public Internet. As the CSES is using Internal Load Balancer only, the traffic through public Load Balancer is blocked. In this scenario, in order to be able to visit the site hosted in CSES, we need to use another service as a jump box to forward the traffic to CSES. In this article, we will use Application Gateway.

 

The traffic flow will be:

Public Internet -> public IP address of Application Gateway -> Application Gateway -> private IP address of CSES -> Internal Load Balancer -> CSES instance

 

 

Configuration guideline

P.S. In order to make the whole process easier to follow, only the basic function of forwarding traffic is realized in this article. If any additional feature is needed, such as HTTPS traffic or WAF configuration, please kindly create a support ticket to Application Gateway team for further assistance.

 

Application Gateway side configuration:

Frontend Public IP address:  (172.191.12.201 in this sample)

Application Gateway frontend IPApplication Gateway frontend IP

Backend pool setting: (Name can be configured as you want. Key point is to use the private, frontend IP address of the Internal Load Balancer)

Application Gateway backend poolApplication Gateway backend pool

 

Backend setting: Setting about how the traffic will be forwarded. In this sample, the easiest simple HTTP traffic with port 80 is used (if CSES project is listening on other port like 700, then here it should be configured as 700). If any additional feature is needed such as HTTPS, custom health probe or path override, please kindly create support ticket to Application Gateway team for further assistance.

Application Gateway backend settingApplication Gateway backend setting

Listener setting: This is about which port of Application Gateway will be used by public Internet to send traffic to CSES. Like here the port 8080 is configured, so when user in public Internet sends traffic to this CSES, he needs to send the traffic to Application Gateway, port 8080. Of course original port 80 can still be used, here using 8080 is to prove that this port can be different from the CSES listening port.

Application Gateway listenerApplication Gateway listener

Rule setting: Combine all the above settings together.

Application Gateway rule 1Application Gateway rule 1

Application Gateway rule 2Application Gateway rule 2

 

 

Test result:

The website hosted in the CSES with Internal Load Balancer is successfully returned back to user in public Internet by visiting Application Gateway IP address (172.191.12.201) plus specific port number (8080).

Test resultTest result

 

 

Additional tips:

Someone may find that in this article, two different load balancing services are used at same time: Load Balancer and Application Gateway. In fact, this point may cause small impact on the performance of network level traffic, but it can help much if we consider about the auto-scaling scenario of CSES.

 

If we only use the Application Gateway in our system, this means the Application Gateway needs to add the private IP addresses of each CSES instance into the backend pool. If our CSES is scaled out (increasing the number of instances), the new instances will use new private IP addresses and those new instances must be added into Application Gateway backend pool manually. This is inconvenient for user.

Published on:

Learn more
Azure PaaS Blog articles
Azure PaaS Blog articles

Azure PaaS Blog articles

Share post:

Related posts

Azure Storage - TLS 1.0 and 1.1 retirement

Overview TLS 1.0 and 1.1 retirement on Azure Storage was previously announced for Nov 1st, 2024, and it was postponed recently to 1 year later...

1 year ago

Efficient Management of Append and Page Blobs Using Azure Storage Actions

  Overview In Azure Storage, Blob Lifecycle Management (BLM) allows you to automate the management of your data based on rules defined by...

1 year ago

[Azure AI Search] Internal Server Error when creating CMK encrypted objects

Scenario Customers follow the Microsoft doc to create CMK encrypted objects (data source, index etc.), but get the 500 Internal Serv...

1 year ago

Optimizing Azure Table Storage: Automated Data Cleanup using a PowerShell script with Azure Automate

Scenario This blog’s aim is to manage Table Storage data efficiently. Imagine you have a large Azure Table Storage that accumulates logs from ...

1 year ago

Optimizing Azure Table Storage: Automated Data Clean-up using a PowerShell script with Azure Automat

Scenario This blog’s aim is to manage Table Storage data efficiently. Imagine you have a large Azure Table Storage that accumulates logs from ...

1 year ago

Restoring Soft-Deleted Blobs with multithreading in Azure Storage Using C#

Blob soft delete is an essential feature that safeguards your data against accidental deletions or overwrites. By retaining deleted data for a...

1 year ago

Performing simple Azure Table Storage REST API operations using curl command.

The blog provides guidance to perform simple Table Storage REST API operations such as Create table, Delete Table, Insert entity, Delete entit...

1 year ago

Bulk delete all the old jobs from the batch account

Deleting a Job also deletes all Tasks that are part of that Job, and all Job statistics. This also overrides the retention period for Task dat...

1 year ago

Utilizing Azure Storage and Runbooks for scheduled automated backups of Azure SQL Databases

In this article, we are going to provide detailed steps to create a scheduled Azure SQL Database backup to storage account using automation. T...

2 years ago

[Azure Service Bus] JMS messages getting dead-lettered

The article discusses a problem where numerous messages end up in the dead letter queue (DLQ) when the JMS service bus consumer connects to th...

2 years ago

Newsletter

Get the latest Dynamics 365 and Power Platform content in your inbox

A curated digest of community blogs, product news, videos, and podcasts — delivered without the noise.

Weekly updates Unsubscribe anytime Fresh community picks
We use your email only for the newsletter and you can unsubscribe at any time.
By subscribing, you agree to the privacy policy.