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.[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.API Management (APIM) - Internal VNet Integration - Developer Portal Connectivity
We have APIM deployed under the Developer Tier with Internal VNet integration. This will only be used for internal APIs across our Azure services and an ExpressRoute connected data centre. We have followed the guide for configuring APIM within the VNet including the NSG. APIM is in a healthy state however we have a connectivity challenge. The solution accelerator denotes a management jump box but other articles allude to connectivity subject to routes, NSGs, firewall config and DNS being in place. We have that in place, we're already able to connect to web services served in Azure from any on premises or Azure service that needs to negotiate our firewall. However APIM appears to have a little more complexity. Please excuse the quickly crafted crude diagram. Despite inbound rule additions for the APIM subnet NSG, connectivity to the Developer Portal isn't possible from any device that has to traverse the firewall. Whereas App Services in similarly configured subnets are accessible over port 443. An AVD VM in the hub VNet which uses system routes and bypasses the firewall connects without issue. We were wondering if anyone else has noted this issue and if there is a resolution without incorporating a jump box in that VNet or in a peered VNet?Implementing Routing Across HUBs in Azure
Hey everyone! I just published a new blog post about implementing routing across HUBs in Azure. If you're interested in Azure networking and want to learn more about how to set up routing between virtual networks, check it out: Implementing Routing Across HUBs in Azure I hope you find it helpful! Let me know what you think in the comments.Azure Secure Virtual Hub VNET-Branch Routing
Hey trying to get connectivity going from our VNET to Branch over the S2S VPN I've setup and from what I can tell when doing a tracert to an branch private ip address it seems to stop at the Azure Firewall IP Address and I've even created an any/any rule on the firewall policy but no go so far. Is there something that I'm Missing? Here is my topology.. Secure Virtual Hub 1x VNET Spoke 1x VPN Site Both associated to the default route table which has a route for 0.0.0.0/0 next hop firewall Both Propagating to the None route table. I have created a DNAT rule to allow RDP which I'm assuming thats how I'm getting into the virtual machine via rdp but once I'm in I cannot route to anything back.Azure Private Link - Implementation
A few days ago, our last post dealt with the Azure Service Endpoint feature, which allows you not to expose your Azure resources to the Internet, for obvious security reasons. Today we are going to see another solution present in Azure, which makes it possible to further restrict the exposure of services, thanks to Azure Private Link. Unlike Azure Service Endpoint functionality, where the endpoint is a category of an Azure service, such as Storage, SQL Database, or Key Vault; Azure Private Link, offers an endpoint that points to a service deployed by the user: To return to Azure Private Link, this feature brings together several concepts: Private Endpoint : Which is your private endpoint with a network interface that uses a private IP address from your virtual network Private Link Resource : Which is the target service you want to consume via its private addressing. Private Link : This is the association between your private endpoint and your target service. Private Link Service : This is what maps a service that is in another VNET behind an Azure Load Balancer Standard. Use case 1: Our first use case is to consume a storage account, and more specifically a blob object, through the Azure private network (Microsoft Backbone) with Azure Private Link. To do this, we deployed the following Azure resources: Storage Account – SA (PaaS Service which will be taken as an example) Virtual Machine – VM Security Group – NSG Public IP address Network Interface – NIC Hard disk – Disk Virtual Network – VNET / Subnet 1. PaaS service exposed on the Internet For our first example, our storage account will have no limitation, and will therefore be exposed on the Internet: (This is obviously not to be reproduced for obvious security reasons, but it helps to better understand the Service Endpoint mechanism) . If we do a test from our machine, we access our file stored on the SA, without any problem: Let's look at our diagram which explains how our SA will be consumed, by our VM, and potentially by other services or external users: When our VM wishes to connect or consume an Azure service, by default, the network flow goes out on the Internet to then arrive on the service concerned, through its public endpoint (DNS), in our case https://saprivatedemo01.%20blob.core.windows.net/demo/file.txt Now let's see what it looks like with Azure Private Link. 2. Enable Azure Private Link Setting up Azure Private Link is not complicated, just follow a few steps: First step, by clicking on Private Endpoint at the SA level: Next, we define the basic information: Then we choose the resource we want to consume, in our case it is a blob file: It is at this stage that we will select the VNET and Subnet in which the network interface will be created, i.e. the private IP of our Private Endpoint: (We do not activate the Network option policy for private endpoints which allows the use of UDRs and NSGs in our example, and we choose a dynamic IP within the subnet). We finish by integrating our Private Endpoint into an Azure DNS private zone, which in this case will be privatelink.blob.core.windows.net : (Obviously you could use an existing Azure DNS private zone or your own DNS server). I can now retrieve the private endpoint saprivatedemo01.privatelink.blob.core.windows.net which I will be able to use instead of saprivatedemo01.blob.core.windows.net While we're at it, we're disabling public access on our SA so that it's no longer exposed on the Internet, which gives us the following configuration: Now let's test from our VM01 that it works correctly through the Azure DNS private zone: A new look at our diagram: We now see that the network flow of the VM no longer goes through the Internet, but directly via Private Endpoint And of course internet traffic is blocked since I disabled it. But how does it work in practice? As we have seen, when you create a Private Endpoint, you create a private IP within a subnet, and therefore within the VNET. But that's not all ! As we can see in the image below, a private DNS CNAME entry is created on the DNS server which manages the saprivatedemo01.blob.core.windows.net zone and which points to the Azure private DNS zone we have created namely privatelink.blob.core.windows.net Use case 2: In this second use case, we want to consume a web service hosted on a VM02 deployed in another VNET02 which has the same address as our first VNET01. Thus this configuration makes it impossible to set up a VNET Peering between the 2 VNETs because of the overlap (overlapping) of the IP addresses of the VNETs. This is where Private Link Service comes in. As we mentioned earlier, we will be able to consume our service, our VM02, through an Azure Load Balancer Standard. We therefore start by creating an internal LB, ie with a private address, namely LB01, in the VNET02 where our VM02 is stored . Let's fill in the basic information: We select the VNET02, letting Azure define its private IP address: Then we define the endpoint on which the traffic will be sent when we arrive on LB01, which will therefore be our VM02: The next step allows you to define a rule that will associate the endpoint with the listening port of LB01, as well as the port on which to send traffic to VM02. We also take the opportunity to create a probe that will check the integrity of the service on the VM02 side : The following configuration steps are not necessary, so you can click on review and create to create the LB. Here is the result after a few seconds: Now that we have created our LB01, let's move on to the next step which is the creation of our Private Link Service. In the search bar of the Azure portal, we search for Private Link, we arrive at the Private Link Center service. We just need to click on Create Private Link Service: Let's start by filling in the information: The next step is important because this is where we will select our LB01, as well as the associated configuration: Then we define, the accesses which allow to consume the Private Link Service: (We limit the access to our subscription, but it is obviously possible to limit only the use to a service, as with our VM01). We can then directly click on review and create to create our Private Link Service. Now that LB01 and the Private Link Service are created, let's move on to the last step, which is the creation of our Private Endpoint. There are two possibilities, the first, returning to the Private Link Center service, the second, going to the Private Link Service that we have just created. For my part, I choose the second option. At the level of my PrivateLinkService01, I will now create my Private Endpoint: On the Resource tab we have nothing to configure, but why? Simply because when creating the Private Link Service we had selected the Auto-approve option , and since we only have one Private Link Service within this subscription, it is selected by default: Then we select the VNET in which to deploy our Private Endpoint, so it's the same one where our VM01 is hosted , ie VNET01. We leave the IP allocation method to dynamic: To date, the DNS option is not supported for a Private Endpoint connected to a Private Link Service , so I will connect through its private IP. We can then directly click on review and create to create our Private Endpoint: I retrieve the IP of the newly created Private Endpoint: All that remains is to test access to my VM02 from my VM01 via the combination of the Private Link Service and the Private Endpoint, which is completely transparent to the user. Everything works as expected: A last look at our diagram shows that we are able to consume the service hosted on VM02 which has the same network addressing as our VM01 , thanks to our internal LB: At the time of writing these few lines, here is the list of Azure services that are currently supported: Azure API Management – General Availability Azure App Configuration – General Availability Azure Automation – General Availability Azure Backup – General Availability Azure Batch (batchAccount) – General Availability Azure Batch (nodeManagement) – Preview Azure Bot Service – General Availability Azure Cache for Redis – General Availability Azure Cognitive Services – General Availability Azure Container Registry – General Availability Azure Cosmos DB – General Availability Azure Data Factory – General Availability Azure Database for MariaDB – General Availability Azure Database for MySQL – General Availability Azure Database for PostgreSQL – Single server – General Availability Azure Digital Twins – Preview Azure Event Grid – General Availability Azure Event Hub – General Availability Azure File Sync – General Availability Azure Files – General Availability Azure HDInsight – General Availability Azure IoT Hub – General Availability Azure Key Vault – General Availability Azure Kubernetes Service – Kubernetes API – General Availability Azure Machine Learning – General Availability Azure Managed Disks – General Availability Azure Migrate – General Availability Azure Monitor (Log Analytics & Application Insights) – General Availability Azure Queue storage – General Availability Azure Relay – Preview Azure Search – General Availability Azure Service Bus – General Availability Azure SignalR – General Availability Azure SQL Database – General Availability Azure Static Web Apps - Preview Azure Synapse Analytics – General Availability Azure Table storage – General Availability Azure Web Apps – General Availability Microsoft Purview – General Availability The list of services can be viewed here: https://translate.google.com/website?sl=fr&tl=en&hl=fr&client=webapp&u=https://docs.microsoft.com/en-us/azure/private-link/availability To sum up, Private Link is an excellent solution for not exposing its PaaS services on the Internet. Today all the services are not yet supported, but the list evolves very regularly. Microsoft encourages the use of Private Link for obvious security reasons, but also to reduce latency by going through the Microsoft backbone, instead of using the Internet.
