Forum Widgets
Latest Discussions
App Connectivity issue
I have come across an issue being reported by one of the user stating that he is unable to connect to an application on port 5672 hosted behind azure internal load balancer. on my observation from Azure portal post login i see thatAzure front end load balancer is marking the front end port as unresponsive/down for service 5672, while the back end port 2009 on azure internal load balancer is seen up on the back end pool virtual F5 .port mapping done properly on azure Error as seen on Azure is “TCP probe out, unhealthy backend instances or unhealthy app listening on port” However when I check on the Virtual F5 the backend server is responding on port 5672 normally, the health checks look ok, thereby the vip is marked as up. is this abnormal behaviour on the application side against 5672 service or something more to check on the azure side which is resulting to TCP probe out error.. pls suggest
IP-based redirection
Hello! I am running a Linux VM on Azure (IaaS) which is providing an SFTP service to the Internet. Sadly, many customers are connecting to this service via public IP address (as opposed to FQDN). I am migrating this service back to on-premises, through a firewall on a different public IP address. Linux VM has public IP 1.1.1.1 right on its NIC. Firewall's IP is 2.2.2.2. I want to redirect traffic to the on-premises firewall. Is there an Azure service/resource that can take inbound connections to 1.1.1.1, then NAT the destination IP to 2.2.2.2 and then also NAT the source IP to 1.1.1.1 or another public IP (like 3.3.3.3) on that service/resource? Thanks!
AZ-700 Step by Step Guide for Azure Private DNS
This article is part of our AZ-700 series, offering a step-by-step guide on configuring Azure Private DNS, based on the tutorial available on YouTube. Ihighly recommend watching the video to gain a solid understanding of the concepts covered in this article. Through this guide, you'll gain hands-on experience in setting up and managing Azure Private DNS, enabling efficient DNS resolution, network segmentation, and seamless automation within Microsoft Azure. In today’s cloud environment, managing network resources and ensuring secure connectivity across virtual networks (vNets) can be complex, particularly when DNS management comes into play. This article provides a comprehensive, hands-on guide to setting up and configuring Azure Private DNS for efficient DNS resolution, network segmentation, and seamless automation in Microsoft Azure. Follow along as we explore the essential elements, from linking vNets and subnets to DNS automation. Why Azure Private DNS? Azure Private DNS allows you to manage and resolve DNS names within a virtual network without exposing them to the public internet. It simplifies domain name resolution, enhances security, and enables automation for dynamic environments. Key benefits of using Azure Private DNS: Dynamic DNS Management: Automatically updates DNS records for new or deleted resources, eliminating stale or "dangling" DNS entries. Domain Delegation: Allows centralized DNS management by delegating your corporate domain to Azure Private DNS. Enhanced Security: DNS records are automatically removed when resources are deleted, ensuring up-to-date and secure network configuration. Quick Recap: Azure Networking Fundamentals Before diving into Azure Private DNS, let’s revisit some foundational concepts from our previous discussions: vNet (Virtual Network): Similar to a traditional VLAN but without broadcast support, a vNet enables secure and scalable resource management. Subnet: Subdivision within a vNet, allowing more granular control over resource segmentation. Azure allows you to set up a single vNet with multiple subnets, maximizing network organization and security without the broadcast overhead typical in traditional networks. Step 1: Understanding Azure Private DNS Azure Private DNS enables the automatic registration of DNS names for resources within your vNet. For example, when you create a virtual machine (VM) in a vNet linked to a private DNS zone, the VM’s name and IP address automatically register within the zone. This streamlines DNS management, especially for dynamic environments where resources are created and deleted frequently. Key Features Automatic DNS Registration: Automatically updates the DNS zone with new or removed resources. Domain Delegation: You can delegate your corporate domain to the private DNS zone, managing DNS records centrally within Azure. Support for All DNS Record Types: Azure DNS supports a full range of DNS records, including A, AAAA, CNAME, and MX records. Step 2: Setting Up the Private DNS Zone 1. Create a Private DNS Zone In the Azure Portal, navigate to Private DNS Zones and create a new zone. Define a name for the DNS zone, such as yourdomain.private. Deploy the DNS zone and navigate to the resource. 2. Link vNets for Automatic DNS Registration Within the Private DNS Zone resource, select Virtual Network Links to connect vNets to the DNS zone. For each vNet (e.g., Core Services, West Europe, Asia), specify the vNet link and enable Auto Registration. This enables seamless DNS name resolution across linked vNets and allows automatic DNS record updates when resources are created or deleted. Step 3: Verifying DNS Resolution and Connectivity Verify DNS Records in the Private DNS Zone: Go to DNS Management under the Private DNS zone and check that the A records for the VMs appear. Connect to VMs via DNS: Use Remote Desktop to access one VM, then attempt to connect to the other VM by its DNS name (rather than IP address). This confirms that the Private DNS setup allows for name-based connectivity. If issues arise (e.g., timeouts), ensure that firewall settings permit connectivity between the VMs. Step 4: DNS Zone Peering Across Regions With Azure Private DNS, you can link vNets across different regions, allowing resources in different geographic locations to resolve names and connect seamlessly. Link vNets Across Regions: Connect the vNets in regions like West Europe, East US, and Asia to the Private DNS zone. Verify Regional Connectivity: From a VM in one region (e.g., Asia), test connectivity to a VM in another region (e.g., East US) using DNS names. Azure Private DNS allows DNS name resolution across regions, ensuring consistent and reliable network connectivity. Summary Setting up Azure Private DNS is a powerful way to automate and centralize DNS management within a virtual network environment. This guide provides a practical framework for deploying Private DNS zones, linking vNets, and verifying connectivity. By configuring Azure Private DNS, organizations can streamline DNS management, secure network configurations, and enhance connectivity across geographically dispersed resources. Next Steps In future tutorials, we’ll explore VNet peering for advanced network configurations, allowing secure communication between isolated virtual networks. Be sure to subscribe and stay tuned for more Azure networking tips and tricks! Let’s enhance your Azure network management with practical, hands-on solutions.
Azure Firewall Application Rules - "MSSQL" not available in Rule Collection Groups
Hi, Working on a IaC project for Azure Firewall. Have created Azure Firewall, Azure Firewall Policy and working on implementing rules using Rule Collection Groups. In the Portal, Application Groups support protocol type "http", "https" and "mssql". However, when provisioning this using the Rule Collection Group module, that is just not an option at all, only HTTP and HTTPS is available: However, in the Azure Firewall module, you have all three: I am more fan of doing this modular, so would like to avoid having to do the rules directly in the Azure Firewall module. Is there any particular reason for why Mssql is not available directly from "Rule Collection Group" module? Is there any Github issue page for Azure networking where I could report this? Thanks!
Azure Network Routing to VPN and Expressroute
I am trying to get Network Routing in azure between the below set up. Vnet A - VPN (peered to workload) Vnet B - Workload Vnet C - ExpressRoute (peered to workload) Each network will be peered to the Workload to allow traffic between them but the VPN Gateway option to allow the peering to be used will be switched off as Azure doesn't support 2 or more peerings with the VNET Gateway feature switched on natively. I have looked for other means using User Defined Routes. I wanted to route any traffic as an example on 10.0.0.0/8 over the Expressroute and then any traffic on 10.222.20./24 over the VPN. Now in theory I thought this would work but in practice it doesn't, the route gets confused where to go and ends up erroring out. My research has led me to believe that its just not achievable without having an Azure WAN in the middle to control all the traffic? Has anyone had any experience with this or used a different method? Thank you in advance.
Azure Web App - Connect to Azure Managed Instance SQL DB
Hi there, need ideas how to let a Azure Web App connect to a Azure SQL DB (managed by Azure Managed Instance). Web App has public network access but no private endpoint: SQL Managed Instance is added to Azure virtual network/subnet. So, Web App is facing to the internet only. SQL Server is connected to the internal network only. Web App cannot connect to sql instance. I tried to create a private endpoint on the managed instance to get it work. But without success. As I am not too deep into the networking part of Azure I hoped to get help how to approach this. I need to be able to connect the web app to the managed instance. Just creating a private endpoint on the Web App ressource shows a warning that this undermines security. So I am looking for a secure way how to achieve connection from Web App to SQL instance/database. Thanks in advance. Additional information: The sql instance and databases are reachable from in Azure running virtual machines that have network adapters in the virtual network where the sql server is running. It's only the web app that is not able to connect (most likely because of missing internal network connection). Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.) ---> System.ComponentModel.Win32Exception (10013): An attempt was made to access a socket in a way forbidden by its access permissions.Default outbound access retirement for VMs and S2S VPN
Hi All, As we now on 30 September 2025 default outbound access for VMs will be retired. https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/ I have on-prem to Azure S2S VPN (on Azure side by means of virtual network gateway + local network gateway). Just wondering if default outbound access retirement may affect the current VPN set up. As far as I can see and understand it should NOT. Just want to double-check myself. Your thoughts on this would be highly appreciated.
Product Manager question - Azure Firewall
I would like to knowif Azure Firewall team has plans to integrate geoblocking based on country codes into Azure Firewall policies? Today, we have to enlist a third party country code list and rebuild IPGroups into our AzFw policies daily. Other products such as WAF and Conditional Access allow for selecting a country code instead of IPv4 addresses.
