Az Virtual Network Manager Multi-Region Hub-Spoke Topology
I'm evaluating Network Manager for a customer with a fairly default topology scenario being multi-region hub-spoke with inter-region meshed hubs. However, I find the existing documentation unclear and the product not intuitive enough on how to achieve this. There is a matching graphic on this following learn article, but the accompanying text above rather mentions the global mesh option to connect spokes in different regions, not hubs... https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke#automation-with-azure-virtual-network-manager My configuration approach so far is: Network groups containing all VNets of a region Hub & spoke connectivity configuration applied with group and selecting matching regional hub VNet Network group of hub VNets Mesh connectivity configuration with global mesh enabled applied to group However, when I look at the visualization, there seems to be no connection among the hubs. Is this the right way or did I miss/misinterpret something?
BGP Routing from and to VPN Gateway
Hello All, I am setting up a lab concerning vWAN connection to onprem via SDWAN and I have some issues getting the routing to work properly. I have a hub which symbolizes the on-premises hub with a VPN gateway (gw-onprem) and a VM (on-prem-hubvm) deployed. Attached to the onprem-hub is a) on-prem spoke with a VM (on-prem VM). b) two vnets that symbolize the sdwan. Both of which have a VPN gateway as well as one VM each deployed (gw-sd-1/2) The SDWan Gateways are connected via s2s to two different vWAN hubs in two different locations. The vWAN has a third Hub which is not directly connected to on-prem What I am trying to lab is what direction the traffic is tacking from the vWAN Hubs to the last on-premise VM. The traffic currently goes all the way through the s2s vpn connection, but it gets dropped afterwards. I am struggling to set-up the routing from the sd-gw's to the on-premises machine. The routing needs to work through BGP The goal of the Lab is to see which path to on-premises is preferred if the hub preference is AS Path (shortest BGP Path). BGP is enabled on all VPN Gateways The SD GWs are peered to the onprem Hub GW but no vnet peering. The on-premises Vnets are peered. Somehow the VPN Gateways are not learning the routes to on-premises. I tried pointing the way with UDRs but somehow it also isnt working I've tried setting up UDRs so that the traffic would be the following vWAN Hub -> sd GW > sd VM > GW-onprem (> on-prem-hubvm) > on-prem VM
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.Az-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!Internal API : Virtual Network support for Power Platform
Hello Everyone, We are using Custom Connectors from Power Automate Flows to initiate a call to the Internal API that is hosted in Azure through the MuleSoft Data Gateway. Since we are unable to activate the private endpoint for this internal API, we are seeking guidance on how to securely connect to the API via V-Net integration. Please advise. As per the Microsoft Documentation : Use custom connectors (preview) to securely connect to your services that are protected by private endpoints in Azure or services that are hosted within your private network. https://learn.microsoft.com/en-us/power-platform/admin/vnet-support-overview Thanks, -Sri
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.Issue with Azure VM Conditional Access for Office 365 and Dynamic Public IP Detection
Hi all, I have a VM in Azure where I need to allow an account with MFA to bypass the requirement on this specific server when using Office 365. I've tried to achieve this using Conditional Access by excluding locations, specifically the IP range of my Azure environment. Although I’ve disconnected any public IPs from this server, the Conditional Access policy still isn’t working as intended. The issue seems to be that it continues to detect a public IP, which changes frequently, making it impossible to exclude. What am I doing wrong?
Problem with Spoke > Hub > on-prem access
I am a little bit lost - maybe there is something in Azure that I do miss. I have a hub/spoke in Azure with on-prem connected via Azure Network Gateway and Site-2-Site tunnel: hub is 172.30.50.0/25 spoke is 10.1.2.0/24 (peered with hub) on-prem is 172.30.50.128/25 VM1 (windows vm) with IP 172.30.50.116 VM2 (windows vm) with IP 10.1.2.78 VM3 (vns3 installed) with IP 172.30.50.119 I don't have the on-prem under control, so: I cannot change there anything. Communication between a VM1 in "hub" and "on-prem" works fine (browser shows page on https://172.30.50.147).Communication between a VM2 in "spoke" and "hub" works fine (browser shows page on https://172.30.50.119, which is the UI of the VNS3 gateway). Routing in "spoke" contains 172.30.50.128/25 next hop virtual appliance: 172.30.50.119. Trying to open https://172.30.50.147 in a browser in VM2 gives me a timeout. Firewall Rules of the vns3: POSTROUTING\_CUST -o eth0 -s 10.0.0.0/8 -j SNAT --to 172.20.153.119 POSTROUTING\_CUST -o eth0 -j MASQUERADE-ONCE FORWARD\_CUST -o eth0 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT FORWARD\_CUST -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT Network Sniffer output: ... IP 10.1.2.78.51118 > 172.30.50.142.443: Flags [S], seq 2875113164, win 64240, options [mss 1418,nop,wscale 8,nop,nop,sackOK], length 0 ... IP 172.30.50.119.51118 > 172.30.50.142.443: Flags [S], seq 2875113164, win 64240, options [mss 1418,nop,wscale 8,nop,nop,sackOK], length 0 ... IP 172.30.50.142.443 > 172.30.50.119.51118: Flags [S.], seq 4142239753, ack 2875113165, win 3954, options [mss 1320,sackOK,eol], length 0 ... IP 172.30.50.142.443 > 10.1.2.78.51118: Flags [S.], seq 4142239753, ack 2875113165, win 3954, options [mss 1320,sackOK,eol], length 0 Status of eth0: no dropped or errors. So, from the network sniffer output, I would assume that the packages are traveling like this: VM2 -> vns3 vns3 -> tunnel -> on-prem-service on-prem-service -> tunnel -> vns3 vns3 -> azure network with destination IP 10.1.2.78 - but never reaching VM2 Does anyone see what I need to do to be able to connect successfully from my spoke to an on-prem server?Public IPs on Azure
Hi, I have been trying to read documentation, but most likely I have used wrong search terms. But does anybody knows if the following kind of setup is possible on Azure? The main idea behind this question is, if I have servers and willing to have centralized FW control for the traffic coming in or out to/from these VMs, is this an option? Or if I assign the public IP to the VM, that can go out directly and skipping the centralized FW? All documents what I have see are speak about assigning the Public IP to the VMs, or having NATing, but with that we hit to the problem when port ranges extends widely.
