Forum Widgets
Latest Discussions
Using Azure Bastion via through vWAN Virtual Hub
I have a feedback about Azure Bastion. I am using the ability to use Azure Bastion with multiple virtual networks via vNET Peering. I would like to extend this feature to use it via a Virtual WAN hub. However, the current Azure Bastion does not seem to detect peering through a virtual hub. I hope Azure Bastion to be able to connect to VM hosts on different virtual networks via a virtual hub.
CloudNetDraw – Instantly generate Azure network diagrams
Hi everyone, I wanted to share a tool I’ve built that might help some of you who regularly document or review Azure network topologies. CloudNetDraw is a free tool that generates Azure network diagrams (HLD and MLD) directly from your environment. It supports both user login and service principals — or you can self-host it. What it does: Visualizes hub and spoke topology Shows all subnets with CIDRs Highlights NSG and UDR presence Exports editable Draw.io files Hosted version available, or deploy it yourself Open source on GitHub Try it here: https://www.cloudnetdraw.com GitHub repo: https://github.com/krhatland/cloudnet-draw Privacy & Security: CloudNetDraw does not collect any information about your network resources or environment. Drawings are generated in memory and deleted immediately after use. We do not store, access, or analyze your topology data. Would love to hear your thoughts or suggestions! Thanks, KristofferAZ-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 https://www.youtube.com/watch?v=UU77GrbCtZg. I highly 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.
Storage not reachable from network using service endpoint.
Hello, Here is the situation. The storage (File share )had assigned networks to allow access. We refresh some changes in the NSG from the network using bicep code ( Outbound was permitted all- no change. Inbound - we updated a name of a rule). What happened: no more access to the storage. No more connection on SMB port. The port was reported as closed. We removed the storage configuration of allowed networks ( the status was still Green), we add it back and magically it started to work. Any hints of what could have went wrong? Thank you
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 that Azure 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 suggestAz-firewall-mon(itor) - near real time Azure Firewall flow log analyser
Hello, networking expert! I’m excited to share with you an update on my personal open source project: az-Firewall-mon: Az-firewall-monitor is an open-source tool that helps you answer to the following question: what is happening in my azure Firewall right now? It provides an alternative and opinionable way to access and inspect Azure Firewall logs, without using Log Analytics or Kusto queries. It provides a simple and intuitive interface that shows you what is happening on your firewall right now (or almost). to filter your data you can use both a full text search or natural language thanks to his integration with chatGPT4. Here a sample full text search interaction: here a sample natural language interaction Try out az-firewall-monitor at https://az-firewall-mon.duckiesfarm.com/ or have a look at the source code on GitHub at https://github.com/nicolgit/azure-firewall-mon Thank you!Deploy Dynamic Routing (BGP) between Azure VPN and Third-Party Firewall (Palo Alto)
Overview This blog explains how to deploy dynamic routing (BGP) between Azure VPN and a third-party firewall. You can refer to this topology and deployment guide in scenarios where you need VPN connectivity between an on-premises third-party VPN device and Azure VPN, or any cloud environment. What is BGP? Border Gateway Protocol (BGP) is a standardized exterior gateway protocol used to exchange routing information across the internet and between different autonomous systems (AS). It is the protocol that makes the internet work by enabling data routing between different networks. Here are some key points about BGP: Routing Between Autonomous Systems: BGP is used for routing between large networks that are under different administrative control, known as autonomous systems (AS). Each AS is assigned a unique number. Path Vector Protocol: BGP is a path vector protocol, meaning it maintains the path information that gets updated dynamically as routes are added or removed. This helps in making routing decisions based on path attributes. Scalability: BGP is designed to handle a large number of routes, making it highly scalable for use on the internet. Policy-Based Routing: BGP allows network administrators to set policies that can influence routing decisions. For example, administrators can prefer certain routes over others based on specific criteria such as path length or AS path. Peering: BGP peers are routers that establish a connection to exchange routing information. Peering can be either internal (within the same AS) or external (between different AS). Route Advertisement: BGP advertises routes along with various attributes such as AS path, next hop, and network prefix. This helps in making informed decisions on the best route to take. Convergence: BGP can take some time to converge, meaning to stabilize its routing tables after a network change. However, it is designed to be very stable once converged. Use in Azure: In Azure, BGP is used to facilitate dynamic routing in scenarios like connecting Azure VNets to on-premises networks via VPN gateways. This dynamic routing allows for more resilient and flexible network designs. Switching from static routing to BGP for your Azure VPN gateway will enable dynamic routing, allowing the Azure network and your on-premises network to exchange routing information automatically, leading to potentially better failover and redundancy. Why BGP? BGP is the standard routing protocol commonly used in the Internet to exchange routing and reachability information between two or more networks. When used in the context of Azure Virtual Networks, BGP enables the Azure VPN gateways and your on-premises VPN devices, called BGP peers or neighbors, to exchange "routes" that will inform both gateways on the availability and reachability for those prefixes to go through the gateways or routers involved. BGP can also enable transit routing among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers. Diagram Pre-Requisite Firewall Network: Firewall with three interfaces (Public, Private, Management). Here, the LAB has configured with VM-series Palo Alto firewall. Azure VPN Network: Test VM, Gateway Subnet Test Network Connected to Firewall Network: Azure VM with UDR pointing to Firewall's Internal Interface. The test network should be peered with firewall network. Configuration Part 1: Configure Azure VPN with BGP enabled Create Virtual Network Gateway from marketplace Provide Name, Gateway type (VPN), VPN SKU, VNet (with dedicated Gateway Subnet), Public IP Enable BGP and provide AS number Create Note: Azure will auto provision a local BGP peer with an IP address from Gateway Subnet. After deployment the configuration will look similar to below. Make a note of Public IP and BGP Peer IP generated, we need this while configuring VPN at remote end. Create Local Network Gateway Local Network Gateway represents the firewall VPN network Configuration where you should provide remote configuration parameters. Provide Name, Remote peer Public IP In the Address space specify remote BGP peer IP (/32) (Router ID in case of Palo Alto). Please note that if you are configuring static route instead of dynamic you should advertise entire remote network ranges which you want to communicate through VPN. Here BGP making this process much simpler. In Advanced tab enable BGP and provide remote ASN Number and BGP peer IP create Create Connections with default crypto profile Once the VPN Gateway and Local Network Gateway has provisioned you can build connection which represents IPsec and IKE configurations. Go to VPN GW and under Settings, Add Connection Provide Name, VPN Gateway, Local Network Gateway, Pre-Shared Key Enable BGP If Required, Modify IPsec and IKE Crypto setting, else leave it as default Create Completed the Azure end configuration, now we can move to firewall side. Part 2: Configure Palo Alto Firewall VPN with BGP enabled Create IKE Gateway with default IKE Crypto profile Provide IKE Version, Local VPN Interface, Peer IP, Pre-shared key Create IPSec Tunnel with default IPsec Crypto profile Create Tunnel Interface Create IPsec Tunnel: Provide tunnel Interface, IPsec Crypto profile, IKE Gateway Since we are configuring route-based VPN, tunnel interface is very necessary to route traffic which needed to be encrypted. By this configuration your tunnel should be UP Now finish the remaining BGP Configurations Configure a Loopback interface to represent BGP virtual router, we have provided 10.0.17.5 IP for the interface, which is a free IP from public subnet. Configure virtual router Redistribution Profile Configure Redistribution Profile as below, this configuration ensures what kind of routers needed to be redistributed to BGP peer routers Enable BGP and configure local BGP and peer BGP parameters Provide Router ID, AS number Make sure to enable Install Route Option Configure EBGP Peer Group and Peer with Local BGP Peer IP, Remote (Azure)BGP Peer IP and Remote (Azure) BGP ASN Number. Also Specify Redistribution profile, make sure to enable Allow Redistribute Default Route, if you need to propagate default route to BGP peer router Create Static route for Azure BGP peer, 10.0.1.254/32 Commit changes Test Results Now we can test the connectivity, we have already configured necessary NAT and default route in Firewall. You can see the propagated route in both azure VPN gateway and Palo Alto firewall. FW NAT Name Src Zone Dst Zone Destination Interface Destination Address Service NAT Action nattovm1 any Untrust any untrust_inteface_pub_ip 3389 DNAT to VM1 IP nattovm2 any Untrust any untrust_interface_pub_ip 3000 DNAT to VM2 IP natto internet any Untrust ethernet1/1 default 0.0.0.0/0 SNAT to Eth1/1 Stattic Route configured: Azure VPN GW Connection Status and Propagated routes Azure Test VM1 (10.0.0.4) Effective routes Palo Alto BGP Summary Palo Alto BGP connection status Palo Alto BGP Received Route Palo Alto BGP Propagated Route Final Forwarding table Ping and trace result from Test VM1 to test VM2 Conclusion: BGP simplifies the route advertisement process. There are many more configuration options that we can try in BGP to achieve smooth functioning of routing. BGP also enables automatic redundancy and high availability. Hence, it is always recommended to configure BGP when it comes to production-grade complex networking.
VPN Gateway - BGP AS PATH - Steer which VPN tunnel traffic will flow form Azure to OnPrem
Can anyone confirm whether in the topology that Microsoft calls "Active-active VPN gateways" we can steer which VPN tunnel is utilized using AS PATH? Or is it by definition active/active, meaning we can't avoid utilizing both tunnels simultaneously and probably we have to deal with asymetric routing? MS article about different topologies: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-highlyavailable#activeactiveonprem My findings: Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual network to your on-premises network will be routed through both tunnels simultaneously, even if your on-premises VPN device might favor one tunnel over the other. However, according to the Microsoft FAQ about BGP: Yes, Azure VPN gateway honors AS Path prepending to help make routing decisions when BGP is enabled. A shorter AS Path is preferred in BGP path selection.
Connecting Azure Databricks VMs to external VNet for Log Analytics ingestion
Hello, We run an ADB cluster using cluster pools. I'm looking for a way connect the ADB cluster pool VMs which reside on the automatically generated Resource Group databricks-rg-<xyz> to another Resource Group and VNet where Log Analytics resource reside. The communication needs to be over private IPs since we block public ingestion in the Log Analytics workspace for security propose. The VMs will report OMS metrics for performance proposes. See this link for more details: https://github.com/Azure/AzureDatabricksBestPractices/blob/master/toc.md#Appendix-A) See following diagram: I found this link: https://learn.microsoft.com/en-us/azure/databricks/administration-guide/cloud-configurations/azure/private-link but I'm not sure it's for this propose. When trying to create the private-link on the ADB resource I have the following options to pick from: "databricks_ui_api" and "browser_authentication", which both seems not relevant for my need. Appreciate your help on this matter. Thank you!
