Azure Container Apps Networking Deep Dive | VNET, Ingress & Private Access Scenarios

 In this video I have addressed - Azure Container Apps “Real World” Networking Scenarios - 

1. Content-web UI Application accessible over internet, content-api accessible only inside container app environment.
2. Content-web UI Application accessible over private network only (from other VNETs), content-api accessible only inside container app environment.
3. Content-web UI Application accessible over private network only (from other VNETs), content-api accessible outside of container app environment, and over private network (from other VNETs).
4. Content-web UI Application accessible over internet, content-api accessible outside of container app environment, and over private network (from other VNETs).
5. Content-web UI and Content-api both accessible over internet.

#AzureBeyondDemos #AzureContainerApps #AzureNetworking #AzureVNET #AzureIngress

#AzurePaaS #AzureCloud #AzureDeepDive

Mandatory NSG Rules URL - https://learn.microsoft.com/en-us/azure/container-apps/firewall-integration?tabs=workload-profiles

If you receive below error - 

Failed to provision IP address: Subscription is not registered for feature Microsoft.Network/AllowBringYourOwnPublicIpAddress required to carry out the requested operation

Solution run below command  in azure cli on portal - 

az feature register --name AllowBringYourOwnPublicIpAddress --namespace Microsoft.Network

How to Make Azure API Management Inbound Public IP Static (No More IP Surprises!)

Recently one of my customer had to go through painful journey of API Management inbound public IP change. This public IP was whitelisted to all client apps, external WAF services, xternal partner application and so on. This overall change of whitelisting of public IP was required at 350+ locations. While the best way is to use domain whitelisting not all firewalls or devices support domain based whitelisting. Or some org still work on public ip whitelisting only. In this scenarios, keeping api management public IP static becomes extremely important. 

I am going to show you the way of azure api management provisioning by which you can always get the static public IP address for inbound traffic. 

In this video I will talk about – 

- Which network option should be used for API Management provisioning

- How you can attach public IP of your choice to Azure api management. 

#AzureBeyondDemos #AzureAPIManagement #StaticIP #AzureAPIM #AzureTips #APISecurity #AzureNetworking #PublicIP #CloudSecurity #AzureBestPractices #AzureVNET #VirtualNetwork

Upgrading Azure Basic Public IP address to Standard sku - part 2

 In this video I will try to answer few important and crucial queries I received on LinkedIn, youTube video comments and so on.

1. Can I upgrade the ip addresses attached to a VM NIC one by one?
2. Can I create new NIC, disassociate all existing basic public ips from old nic, perform the upgrade to standard and then attach to new NIC?
3. Can I disassociate all existing basic public ips from current nic, perform the upgrade to standard and then attach to same existing NIC?
4. What if I have my public IP basic, static and not attached to anything, can I upgrade?
5. Does this upgrade involve downtime? If yes, how much? Or how can I calculate?
6. Is there a way to rollback upgrade in case of failure?
7. Whom I should involve during the activity?

#azure #azurevm #publicIP

Part 1 Video is here - https://www.sanganakauthority.com/2025/03/upgrading-basic-public-ip-address-to.html

Azure Virtual machines should be connected to an approved MULTIPLE virtual networks

 8 min to read.

Abstract

Virtual machines should be connected to an approved virtual network - This default Azure policy is fantastic. This policy checks if a VM is part of approved VNET; else it shows compliance message.

However it only offers VMs to be checked against single VNET name. In reality, we have flood of Azure VNETs across multiple Azure subscriptions.

So we need a policy that can check all Azure VMs against “multiple azure Virtual Networks”.

This article talks about creating a policy that allows to provision Azure VMs inside only allowed list of VNETs.

 

The Challenge

This policy will be built as custom. I want to do below –

Evaluate every NIC against the VNET names present in input parameter. Refer yellow and green highlight below. I need to –

1.       Loop using for or for-each

2.       Dynamically get values of all items present in a parameter after performing “split” on the input string.

 

  "mode": "All",

  "policyRule": {

    "if": {

      "allOf": [

        {

          "field": "type",

          "equals": "Microsoft.Network/networkInterfaces"

        },

        {

          "not": {

            "field": "Microsoft.Network/networkInterfaces/ipconfigurations[*].subnet.id",

            "contains": "[parameters('virtualNetworkIds')]"

          }

        }

      ]

    },

    "then": {

      "effect": "[parameters('effect')]"

    }

  },

  "parameters": {

    "effect": {

      "type": "String",

      "metadata": {

        "displayName": "Effect",

        "description": "The effect determines what happens when the policy rule is evaluated to match"

      },

      "allowedValues": [

        "Audit",

        "Deny",

        "Disabled"

      ],

      "defaultValue": "Audit"

    },

    "virtualNetworkIds": {

      "type": "String",

      "metadata": {

        "displayName": "Virtual network Names",

        "description": "Resource name of the virtual network. Example: Add , separated multiple values."

      }

    }

  }

}

The input parameter to this policy will be more than one names of VNETs. Unfortunately in Azure policy I could not find a way to iterate over input parameters by using for-each loop construct.

There is a Current function available however it can be used only when we are using Count and Where function. Also these functions are used over Field property, used as an array. These functions cant be used when input parameter is not an array.

Therefore we need a way to iterate over input parameters array and comparing every parameter value with one subnet id Field highlighted as green above.

Solution

If we see the outcome of below line  - "Microsoft.Network/networkInterfaces/ipconfigurations[*].subnet.id",

It will be resolved to id format of subnet similar to below - "/subscriptions/SubId/resourceGroups/rg--net/providers/Microsoft.Network/virtualNetworks/vnet-01/subnets/default"

So we just need to use expertise string functions lie split, combine, concat etc. in a such a way that we take out only VENT name from above string. Therefore lets write code to covert to string and then split so as to get VNET name. Final code is as below –

"[split(string(field('Microsoft.Network/networkInterfaces/ipconfigurations[*].subnet.id')),'/')[8]]"

Creating Custom Policy

Login to Azure portal -> In middle top search box type “Policies” -> Select Definitions -> Create New. Then add values as shown below. The name of the policy I have given as “Azure Resources should be connected to an approved virtual networks”. Code of policy to be added under section “POLICY RULE” can be taken from github link shared below.

Also whenever we create custom policy always get it added in new Category as “My Custom Policies”. Do not add any Role Assignment. Then save to finish policy creation wizard. [click to get better view.]

Open the newly created policy and click on Assign. [click to get better view].

On the Basics tab, make “policy enforcement” option as disabled. We want to just view the report of azure resources not deployed in approved VNET. If we enforce policy means it will not allow to provision new resources in any of the VNET other  than listed in parameters tab below. For testing purpose I disabled policy enforcement.

Under “Remediation” tab uncheck the option “create a managed identity”.

On Parameters tab, make sure that you add names of all VNETs against which you want to evaluate azure resources is added in below shown format only. Then Click on “Save” button for VNET names added and click on “Review and Create” to complete assignment process.

Output

Virtual Machines

I could see that Virtual Machines not listed under the VNETs I added as parameter. Refer screenshots [click to get better view] –

Same policy will also be automatically applied on Azure App Service configured with private endpoint. Refer below output –

Full and final working policy is present at this Github link –

kunalchandratre1/NicVnetPolicy:This repo has code related to Azure policy to identify Azure resources whichare not deployed in approved VNETs. (github.com)

Important –

This policy will not work for Azure Kubernetes Service, VM Scale Sets as their NIC resource provider format is different. However this policy should work as is for all types of private endpoints where NIC is create with resource provider format of Microsoft.Network/networkInterfaces/.

I have not tested with other types of private endpoint. Please test it and add your experience in comments.

Conclusion

Hope this article helped you to build custom policy and helped to achieve your compliance and governance. Let me know your views in comments section below to improve and what are your thoughts on this approach.

Happy Azure Governance!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Start stop multiple Azure VMs on schedule and save cost!

Export Azure VMs to CSV!

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!

PaloAlto NGFW, F5 WAF and DDoS - Proven Azure Architecture Patterns

14 min to read.

Abstract

I have been part of many Azure Landing Zone implementations in last 1.5 years. Many organizations are already invested on below security devices –

1.      F5 WAF – Web Application Firewall

2.      F5 DDoS – Distributed Denial of Service

3.      PaloAlto NGFW – Next-Generation Firewalls

Enterprises have inclination to use same devices on Azure as well. Not only because they are invested in licenses costs but also on skillset cost. There are dedicated [paid] teams managing these devices and logging, monitoring, SOC, incident management, dashboards everything is already streamlined for them.

This article talks about Azure Architecture patterns I have seen across many organizations Azure Deployment using F5 WAF, DDoS and PaloAlto NGFW.

Note - Below I am considering incoming traffic from internet and outgoing to internet. I am not talking about Azure-OnPremises connectivity scenario in below architecture patterns.

Also recommendations as per my experience; deploy the security devices in dedicated VNET and configure all applications in separate VNET [Hub-Spoke!].

Azure Architecture Pattern 1

Refer to first pattern on deploying F5, PaloAlto devices in combination on Azure – [Click on image to get better view].

Pattern 1 Description

1.      The traffic from internet lands on public IP attached to External Standard Load Balancer [Layer 4] of Azure in front of F5 DDoS VMs.

2.      On External Azure Standard load balancer you can configure inbound public Ips. These public Ips can be added as per number of applications sitting behind your internet DMZ.

3.      DDoS Azure VMs are configured as Active-Passive or Active-Standby. At any given point only single Azure VM of F5 DDoS is serving the incoming requests from internet.

4.      PaloAlto NGFW VM-Series Azure VMs are configured as active-passive. It has an Azure Standard internal load balancer in front of it for load balancing and HA achievement. For monitoring purpose it is required to know incoming source IP at firewall; therefore we did not perform SNAT on DDoS. However at PaloAlto VM-Series firewall on Azure we can perform SNAT [if need be].

5.      F5 WAF VMs are present behind the PaloAlto NGFW. F5 WAF is also configured in Active-Active configuration. It has an internal load balancer in front of it for load balancing and HA achievement.

6.      F5 WAF machines do not have any public IP assigned.

Where do we perform SSL Offload?

To inspect incoming traffic; SSL offload is mandatory. Without SSL Offload packet can’t be inspected/ verified if it is valid traffic or malicious traffic. Therefore in above Azure Architecture pattern we should perform SSL Offload on F5 DDoS VMs. Post which you can inspect traffic on PaloAlto NGFW and F5 WAF.

What if I want to achieve end to end SSL on incoming traffic?

Perform SSL Offload on F5 DDoS Azure VMs. Then let traffic be inspected on F5 DDoS, PaloAlto NGFW and F5 WAF Azure VMs. On F5 WAF itself post inspection you re-configure the leaving traffic with new SSL certificate. So after F5 WAF when traffic goes to application VMs then it will be accessed over internal private IP communication; over HTTPS. This is end to end SSL.

How my outbound traffic “generated within my Azure environment” will flow?

In above diagram we have configured/ assigned public IP directly to one of the Azure PaloAlto VM. So traffic initiated from Application VMs directly goes to Azure PaloAlto VM and then it goes out to internet. In this traffic flow, F5 WAF and F5 DDoS Azure VMs do not come in to picture.

Make sure you attach separate public IP to one of NIC of each PaloAlto Azure VMs.

In case you want to ask 3^rd party company to whitelist your outgoing IP in their firewall; then both Ips of firewall will be required to whitelisted.

Note - If you fear of exhausting SNAT ports for Azure PaloAlto VM then you can also configure Azure NAT gateway in same subnet of PaloAlto NGFW external/ internet interface and use it for all outbound traffic. I have not tried this but should be pretty straight forward.

Azure Architecture Pattern 2

Many times customers prefer to use separate public Ips for inbound and outbound traffic. Separate outbound traffic public IP helps in whitelisting at their customers end. Example, WoodGrove org has api which will be called from Azure environment of Contoso company. So WoodGroove will ask Contoso to provide public IP range from which the api will be called. In this case Contoso will share the public IP to WoodGroove, specifically attached for outbound traffic “generated within Azure”.

In above pattern #1, we have public IP attached at the F5 DDoS Azure LB and also to the PaloAlto NGFW VM-Series. Sometimes customer do not want any public to be attached other than entry point. This can be addressed using below pattern. [Click on image to get better view].

Pattern 2 Description

1.      The traffic from internet lands on public IP attached to External Azure Standard Load Balancer [Layer 4] of Azure in front of F5 DDoS Azure VMs.

2.      On External Azure Standard load balancer you can configure inbound public Ips. These public Ips can be added as per number of applications sitting behind your internet DMZ.

3.      DDoS Azure VMs are configured as Active-Passive or Active-Standby. At any given point only single Azure VM of F5 DDoS is serving the incoming requests from internet.

4.      PaloAlto NGFW Azure VMs are configured as active-passive. It has an Azure Standard internal load balancer in front of it for load balancing and HA achievement.

5.      F5 WAF VMs are present behind the PaloAlto NGFW. F5 WAF is also configured in Active-Active / Active-passive configuration. It has an internal load balancer in front of it for load balancing and HA achievement.

6.      F5 WAF and PaloAlto NGFW VMs do not have any public IP assigned.

7.      Standard Azure load balancer attached in front of F5 DDoS also has outbound rules configured. To know more refer - https://docs.microsoft.com/en-us/azure/load-balancer/outbound-rules#scale.

8.      SSL Offload still happens at F5 DDoS Azure VMs.

9.      There is no SNAT performed for incoming traffic at DDoS therefore source IP is visible in PaloAlto NGFW Azure VMs.

 

How my outbound traffic “generated within my Azure environment” will flow?

In above diagram we have configured/ assigned public IP to External Azure Standard Load Balancer; present in front of F5 DDoS Azure VMs. Therefore we will need to configure UDR [Azure Route Tables] to make outbound traffic flow in below sequence –

App VM -> F5 WAF -> PaloAlto NGFW -> F5 DDoS -> Azure Standard LB -> Internet

In this case, outbound traffic flowing through F5 WAF and DDoS do not add any value. However as customer requirement is not to allow any public IP other than entry point; we will have to make traffic flow through each of the device. Here F5 WAF and DDoS will act only as pass through for traffic and adding extra hops.

Azure Architecture Pattern 3

When I implemented Azure Landing Zones at financial organizations many of them asked a variation in above patterns with Proxy deployment on Azure for Outbound traffic. So for outbound traffic below can be another architecture pattern where traffic flows as - >

App VMs-> Proxy VMs -> PaloAlto NGFW VMs -> Internet.

Same approach can also be used for pattern #2 above. Below is architecture for Pattern # 1 with Proxy – [Click on image to get better view].

Azure Architecture Pattern 4

While we can have entry point on Azure Internet DMZ Zone through F5 DDoS BIG IP on Azure VMs; we can achieve the high availability WITHOUT USING Azure Standard Load Balancer as well.

Refer to below diagram for the same - [Click on image to get better view].

In above diagram assuming we want to retain Source IP to Firewall level; we can configure DDoS F5 Azure VMs in Active-Passive.

In the diagram, for F5, in the event of a failover, the IP configuration is deleted from active device and recreated on that standby device’s network interface. So your public IP [virtual IP] on which traffic lands remain same irrespective of which VM is serving the requests.

This failover is API call based failover and well explained here - Azure(f5.com).

Same API based failover can also be achieved for F5 WAF device. Also you can keep adding secondary public IP addresses per application being onboarded behind this DMZ zone.

Azure Architecture Pattern 5

I have many organization using PaloAlto Azure VMs Firewall for outbound and inbound combined had to use bigger size VMs. There is another deployment pattern I have seen where separate Azure PaloAlto Firewalls are used for inbound and outbound.

In this pattern we will need to perform mandatory SNAT at F5 WAF level to allow return traffic reach to correct destination of F5 WAF and outbound traffic generated within app layer to reach to outbound PaloAlto Azure VM. Refer to below diagram for details - [Click on image to get better view].

Here we are having two public Ips attached to one of the NIC of each of outbound PaloAlto NGFW. So that based on current active VM the outbound traffic flow outside to internet.

Remember you will need UDR configured in app layer in such a way that traffic destined to internet will flow to PaloAlto NGFW Azure VMs and rest of the traffic should flow to F5 WAF.

Is there a way to run F5 BIG-IP DDoS on Azure on entry point in Active-Active with No SNAT?

If you want to preserve incoming source IP till firewall/ app layer then SNAT should not be used. If we plan to deploy F5 DDoS in Active-Active then SNAT is required. Otherwise return traffic does not understand which was VM devices to be used for return/ response traffic. In this case source IP of incoming traffic will not be visible to firewall. In such case many customers take below approach –

1.      Configure SSL Offload on F5 DDoS

2.      Configure F5 DDoS in Active-Active with SNAT.

3.      Add incoming Source IP in X-Forwarded-For [XFF] header.

This is fine if you firewall devices are able to block incoming malicious IP present in XFF. If not, then Active-Passive will make more sense.

Should I always have F5 DDoS on front irrespective of order of devices?

DDoS is for protection of traffic coming from internet. So for internet facing applications, you should always have DDoS in front of everything.

I see PaloAlto NGFW VM-Series on Azure is mentioned as Active-Standby / Active-Passive only? Can it work in Active-Active mode?

As of today PaloAlto VM-Series firewall on Azure can not work in Active-Active mode. Refer to the document for more information - VM-Series in High Availability (paloaltonetworks.com)

Do we need to perform SNAT on PaloAlto VM-Series Firewall?

If you don’t want to retain source IP forwarded from DDoS devices beyond PaloAlto NGFW Azure VMs then you can certainly perform SNAT on PaloAlto VM-Series Firewall Azure VMs. IF you want to retain source incoming IP till application layer then “Do not” perform SNAT on PaloAlto firewall device.

How to preserve Incoming Source IP of internet till Azure application layer VMs?

Many organizations require incoming source IP to be preserved till application layer/ firewall layer for monitoring/ business requirement/ logging/ audit purpose. If this is the case then you will need to configure the F5 DDoS Azure VMs in Active-Passive or Active-Standby mode.

This way Source IP of internet is not NATted on F5 DDoS Azure VMs and it is visible in PaloAlto NGFW layer. If SNAT is configured on DDoS then PaloAlto NGFW will never see real incoming source IP from internet.

Similarly to preserve the source IP beyond PaloAlto Azure firewall; you will need to avoid SNAT on PaloAlto Azure VM-Series and F5 WAF devices.

Refer to Pattern 5 which stated how can you have incoming source IP taken to App layer in XFF header through F5 WAF device. Or you can simply avoid SNAT n F5 WAF Azure VMs also and you will get source IP as internet IP in application layer..

Conclusion

There can be many combinations of the security devices of F5 and PaloAlto on Azure. The above mentioned architecture patterns I have seen at most of the places on Azure. Hope this article helped to design combination of F5, PaloAlto on Azure.

If you have any recommendations to make article better, reach out to me. I will be more than happy to update the article.

Happy NVAs on Azure!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Restrict Azure Firewall access from Owner and Contributors of Azure Portal

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Acomplex design – Site to Site VPN, VNET Peering and 4 VNETs – how to solve using Azure Firewall?

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM

Transitive Routing and Site to Site VPN, Azure Firewall, VNET Peering, 4 VNETs

14 min to read.

Abstract

In earlier blog I talked about solving transitive routing problem in 3 VNETs. Recently I came across a situation where transitive routing was required across 4 layers.

A (On-premises DC) < site to site VPN> B (VNET with VPN GW) < peered to> C (Firewall VNET) < peered to> D (server app VNET).

Interested to know how to achieve transitive routing across 4 VNETs? Read on.

Problem Statement

Let us understand the problem better by using example. [Click to get better view]-

Requirements are as below -

1.      Contoso company has on-premises DC connected to Azure Landing Zone VNET using Site to Site VNET.

2.      Server Deployment should be done in separate VNET and all traffic should be monitored using Firewall

3.      The firewall must be placed in separate VNET for logical separation and more granular control.

4.      Communication between OnPremises DC server to Azure Server VNET must pass through S2S VPN, Firewall in both directions.

This is classic Transitive routing scenario in Azure, but a complex one. There are 4 networks and you need connectivity between first and fourth; without having them connecting directly.

Let us solve this one by one.

Solving on premises DC connectivity to Azure Landing Zone VNET

I don’t have any on premises site for demo. Therefore I created Azure VNET only and will be treating it as on premises site.

So we have 2 Azure VNETs across which we need connectivity. You can easily set it up using VNET to VNET connection or using VPN Gateway connection. However to replicate real world scenario we will create Site to Site VPN between On premises DC and Contoso Landing Zone Azure VNETs; using Azure VPN Gateway in each.

Connection between Server VNET to Firewall VNET

Server VNET needs to send data [ in our case we will just try RDP] to on premises DC VM. However they are not connected directly.

Also traffic to/ from server VNET has to be filtered through firewall. Therefore we created separate VNET for Server and firewall. I decided to use Azure firewall and the VNET is called as Transit VNET below.

As Server VNET just receive / send data to/ from Azure firewall; we need Standard VNET Peering between Server and Transit VNET.

Connection between Firewall VNET to Landing Zone VNET

Data from Server VNET VMs need to be sent to on premises. However it has to be passed from Azure firewall. Therefore we need Transit VNET to send data to on premises in reality.

So we want traffic from firewall VNET to reach to contoso on premises DC VNET using S2S VPN Gateways present in both VNETs.

For this we will need to setup VNET Peering with Remote Gateway option between Transit VNET and Landing Zone VNET. Only Standard VNET peering won’t work in this scenario.

Final Solution Architecture looks like below

[click to get better view].

Setting up Site to Site between Azure VNETs

We need to create two Local network gateway as shown in above diagram. You need to take care of below when you create S2S between Azure VNETs using Azure VPN Gateways.

1.      Create Contoso DC Local network gateway and assign public IP of Contoso DC VPN GW. Assign range of on premises DC private VNET.

2.      Create Contoso Zone Local Network Gateway and assign public IP of Contoso Zone VPN GW. Assign ranges of Server, Transit and Zone private VNET.

Refer below screenshots – [click to get better view]

Then to setup Site to Site IPSec tunnel follow the guide as describe here - Tutorial- Connect on-premises network to virtual network: Azure portal - Azure VPN Gateway | Microsoft Docs

Refer below screenshots – [click to get better view]

This completes the S2S connection between 2 Azure VNETs using Azure VPN Gateway.

Provision Azure Firewall and Add Network Rules

Create dedicated subnet for Azure Firewall in Transit VNET and then create Azure Firewall in Transit VNET.

We want RDP traffic from Server VNET to DC VNET and vice versa to allow through Azure Firewall. Therefore add below rules in Azure Firewall network rules. [click to get better view]

Setup VNET Peering between Server, Transit and Zone VNETs

First configure server VNET to Transit VNET peering as shown below. Here as both VNETs to dot have Azure VPN Gateway; so this will be standard VNET peering. [click to get better view]

Then configure Transit VNET to Zone VNET peering. Here Zone VNET has Azure VPN Gateway and we want traffic filtered from Transit VNET firewall to pass to on premises DC VNET over S2S.

Therefore use remote gateway setting in Transit VNET peer, and “Use this VNETs Gateway or Route server” setting in Zone VNET peer as shown. [click to get better view].

This step completes all the required peering setting as per architecture diagram.

Configure Azure Route Tables

From Server subnet we want traffic to go to Contoso DC and pass through Azure Firewall. Therefore we need to add below rules on server subnet –

1.      If destination is Contoso DC VNET then next hop is firewall IP

2.      If destination is Zone VNET then next hop is firewall IP

Then assign route table to server subnet as shown below. [click to get better view].

The traffic received on Contoso Zone GW and destined to server vnet should also be passed always to firewall. Therefore we need to add below rules on Zone Gateway Subnet route table –

1.      If destination is server VNET then net hop is firewall IP.

Then assign route table to Gateway subnet of Zone VNET. [click to get better view.]

This completes configuration of all Route tables.

Confirm the connectivity between Server and On Premises DC VNET

Login to Server VM using public IP. Then simply ping to on premises Dc VM. The ping should be successful as shown below. If we try to take RDP to On Premises DC VM over private IP from server VM; it should be successful as shown below. [click to get better view].

You can view the source address of server VM from event viewer as below – [click to get better view]

Similarly RDP from On Premises DC server to Server VM over private IP should also be successful.

Conclusion

Hope this article helped to design Transitive Routing across 4 VNETs.

Happy Peering!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Transitive routing across 3 VNETs using Ubuntu VM

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM