Forum Widgets
Latest Discussions
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!
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.
Please Continue Supporting Private Link for Azure Function origins in Azure Front Door Premium
We recently opened a support case because we are no longer able to enable private link using the Azure Font Door User Interface in the Azure Portal to Azure Function origins that reside in our ILB Application Service Environment (ASE) V3 within an Isolated V2 Azure App Service plan. We need this feature enabled again, but we received the following response regarding this issue. “We just received update on the issue from product level team, actually the private link is not supported for function app, it used to be worked by accident. So they started removing it now, they blocked it on portal, further they will be doing it for CLI/PowerShell as well. The previous function apps for which the private link is enabled and working fine will be disassociated at any time. Unfortunately, they suggested users to not go with private link for function apps anymore.” Private link to Azure Functions apps running an Isolated V2 Azure App Service plan is supported by Azure Front door; the feature should continue to be supported and subject to the Azure Front Door SLA. It is possible to create Private Links from Azure Front Door to Azure Functions origins that reside in our ILB ASE V3 within an Isolated V2 Azure App Service plan. We have created Private Links from Azure Font Door to our Production Azure Functions, and they have been connected since 2022. The Azure Front Door documentation references that the product supports Private Link for both Azure App Service and Azure Function origins. 1. We were previously able to enable private link from Azure Front Door, using the User Interface in the Azure Portal, to Azure functions origins that reside in our ILB Application Service Environment (ASE) V3 within an Isolated V2 Azure App Service plan. The Azure Front Door documentation contains language that supports that Azure Front Door supports Private link for Azure App Service and Azure Functions origins. Stated in the doc “Secure traffic to Azure Front Door origins.” “Private Link origins When you use the premium SKU of Front Door, you can use Private Link to send traffic to your origin. Learn more about Private Link origins. You should configure your origin to disallow traffic that doesn't come through Private Link. The way that you restrict traffic depends on the type of Private Link origin you use: Azure App Service and Azure Functions automatically disable access through public internet endpoints when you use Private Link. For more information, see Using Private Endpoints for Azure Web App.” Secure traffic to origins - Azure Front Door | Microsoft Learn Stated in the doc “Connect Azure Front Door Premium to an App Service origin with Private Link using Azure CLI” “Private endpoints requires your App Service plan or function hosting plan to meet some requirements….” https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/how-to-enable-private-link-web-app-cli 2. Azure functions can run in an App Service plan and support for private endpoint and private link for Azure App Service and Azure Functions is generally available. Azure Private Link availability | Microsoft Learn Connect privately to an App Service apps using private endpoint - Azure App Service | Microsoft Learn https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options?tabs=azure-portal#private-endpoints 3. We are now unable to enable private link using the Azure Font Door User Interface in the Azure Portal to Azure functions origins that reside in our ILB ASE V3 within an Isolated V2 Azure App Service plan. We need this feature enabled again. 4. We are still able to enable private link to Azure function origins that reside in our ILB ASE V3 within an Isolated V2 Azure App Service plan with the Azure CLI. I recently discovered the Note was added to the azure-docs on April 25th, 2024, which is after we opened our support incident: https://github.com/MicrosoftDocs/azure-docs/commit/6d7d40b4a9c0b1e843aa81a121ecb83468043803 The reference to Functions not being a supported feature is false and I request that is removed.
Understanding HUB vnet route tables relation
Hi there Please help me understand the relation/usage between/of the different route tables in a Hub vnet. Let's say I have a Hub vnet with ExpressRoute GWs for on-prem connectivity, and VPN GWs for Vnet-Vnet VPN connections to other HUBs. Spokes are peered to the Hub. The ER GW holds a route table. The VPN GW. holds its route table. And the GatewaySubnet holds a route table. I can view the ER GW Private Peering route table. I can see the BGP Peers/Routes in the VPN virtual gateway. But in the hub I cannot really see the effective GatewaySubnet route table. (I know I can by deploying a VM in a subnet in the hub) When exactly is the GatewaySubnet route table consulted/used? In which flows? Please elaborate on the GatewaySubnet vs. ER GW vs. VPN GW route tables and their exhange of routes or lack of. Thanks in advance! /Thomas
Redirection pulic IP adress of vm azure to local adress on premise
Hello, I have VM on azure and other one on premise, the VM on premise access to antenna, which is located in premise, and I have installed VPN between vm azure and vm on premise, Antenna on premise: ip 10.10.18.2 Vm on premise: ip 10.10.19.3 …………………………………… there is connection between antenna and vm on premise. Vm on azure: ip 10.10.19.2 , Public address : 10.40.40.40 ………………….. Ther is connection between vm azure to antenna ( I have set route 10.10.18.0 to 10.10.19.0). I want to access to this antenna from synapse by Rest API service, so I wonder how i can redirect public address of vm on azure to local address of antenna on premise through vm azure?KQL Query for finding out resource's egress going through a specific Virtual Network Gateway
Is there a way to find out individual resources egress that are going through a Virtual Network Gateway VPN. Pretty much I have an issue where its been noticed that there's high egress going through our Azure to on-prem VPN, I believe it's due to backups but I want to find the specific resources that are causing it. Is there a KQL or way of logging that would be able to pull the individual resource names or resource IDs based on their egress going through a Virtual Network Gateway?
WordPress App how to restrict access to specific pages on the site
Hello all, I have a WordPress App hosted on Azure and I am struggling with how I can secure specific pages from public access. For example: www.mysite.com/wp-admin www.mysite.com/info.php I'd like it so that only specific IP addresses or Microsoft user accounts can access some, such as admin pages and for some pages I'd like no access at all, to where it just blocks any sort of visit. I've viewed the documentation for Front Door and some networking restrictions but that seems to be just IP addresses and I'm confused about how I can set those rule for specific pages within the App. I know WordPress offer plugins which have this sort of functionality but I'd like to take advantage of Azure's security features rather than plugins from WordPress. Any help is very appreciated. Thank you[New post] A first look at Azure Event Grid MQTT support
Have a first look at Azure Event Grid MQTT support. In this post, we see how the 'IoTGrid' stops client spoofing, a common security challenge. See how to connect Node-RED and Advantech IIoT industrial clients. We route enriched messages to other Azure services. Read the full story at: https://sandervandevelde.wordpress.com/2023/10/14/a-first-look-at-azure-eventgrid-mqtt-support/ #mvpbuzz
Load Balancer Session Persistence and Existing Connections Clear Information
Hi, Going on Azure documentation on session persistence for Load balancers and reading the following on client IP and protocol: 1) It is mentioned in this article that Client IP and protocol settings is used to solve an incompatibility issue between Azure Load balancer and the Remote Desktop Gateway. In the scenario mentioned that TCP and UDP are used with client ip address and protocol. If I understand correctly this setting should send UDP from same client to a different load balancer. So it does not solve this problem. 2) The behavior of existing connections through a load balancer. As per my understanding TCP connections will not be rebalanced to a new backend instance after a failure while UDP will actually be sent to another VM as it is connectionless. is this somehow related to the persistence settings ? Does Azure have any workaround for this behavior. For example GCP has this feature of rebalancing existing connections. Thanks.
Alert rule for SLB metrics at scale
For one single SLB, we can create alert rule to monitor SLB metrics like data path availability, health probe status. But when creating alert for SLB from resource group or subscription level, SLB metrics like data path availability and health probe status are not available. If there're hundreds of SLB needing alert rule to monitor SLB metrics, current situation will make maintenance more complicated. Please considering to support creating alert rule for SLB metrics at scale.
