Known issue: Upgrading Microsoft Tunnel version 20260129.1
We identified an upgrade issue with the early March release of Microsoft Tunnel version 20260129.1 that caused servers to become stuck and unable to complete the upgrade. The issue can be resolved by uninstalling and reinstalling the server to a newer version (20260330.1 or later). Alternatively, we’ve created a script to help you update affected servers. This blog explains how to use the mstunnel-patch-2602 script to remediate the issue. Before you begin Before you run the script, make sure you have the following: Access to the Linux virtual machine hosting the Microsoft Tunnel server Permission to run commands with sudo The patch script downloaded to the server from https://aka.ms/mstunnel-patch-2602 When to use this script Use this script if your server is showing one or more of the following behaviors: The server remains on the affected version (20260129.1) and doesn’t move to the latest version In the Intune admin center, the server health state appears as Healthy, but the upgrade banner shows an error The server rolls back to the affected version because of a version mismatch in Agent Settings Identify impacted servers The issue affects servers on version 20260129.1, use the following hash to identify whether your deployment is on this version: Agent: sha256:abbdcd854aa5ac376aed32c828e4c84917e776a701855cd1e3febed18a3e4dae Server: sha256:ad57d6a7ffe21f64fc1577713063ae9b180914cf65bc70b4e49be21299cfc1d3 The issue was resolved with version 20260330.1, released March 30, 2026. You can verify your servers are on this version with the following hash: Agent: sha256:163214b94af6d91a5ef02690f891c5a41e87b1059b9530324716ee34778c1785 Server: sha256:dd62c292528e8e5aa4e7b84418efa42fd3830ec0db40467947cde8125aa17d7e Run the script After downloading the script to the server, complete the following steps. Step 1: Enable execution permissions If needed, make the script executable: chmod +x mstunnel-patch-2602.sh Step 2: Run the script Run the script with elevated permissions: sudo ./mstunnel-patch-2602.sh When the script runs, it performs the following actions automatically: Checks whether the current server is using the affected build hashes. Creates backups of the current configuration so the system can revert if the update fails. Stops the Tunnel agent and server services. Updates the configuration with version 20260330.1 hashes Pulls version 20260330.1 and forces mst-cli install without requiring additional user input Expected results After the script completes successfully, the server should be updated to the March 30, 2026 version 20260330.1. This remediation is intended to resolve upgrade failures caused by a version mismatch and eliminate the need for a manual uninstall and reinstall workflow. If you have any questions or issues running the script to update your servers, reply to this post or reach out to the team on X @IntuneSuppTeam.Debunking the myth: Cloud-native Windows devices and access to on-premises resources
By: Roger Southgate - Sr. Product Manager | Microsoft Intune Myth vs reality Myth: Cloud-native Windows devices can’t access on-premises resources such as file shares or legacy applications. Reality: With minimal or no configuration, cloud-native devices can seamlessly access on-premises resources using NTLM or Kerberos. Introduction Microsoft’s vision for secure, productive workplaces is clear: adopt cloud-first services, integrate Zero Trust throughout, and deploy Windows 11 devices as cloud-native endpoints to stay agile and future-ready. If you’re yet to begin this journey, review the Set up and configure a cloud-native Windows endpoint with Microsoft Intune tutorial. For context, a cloud-native device is a Windows device, joined to Microsoft Entra and managed by Intune. No domain join, no group policy, and no Microsoft Configuration Manager required. Leveraging complementary services such as Windows Autopilot and Windows Autopatch enables users to self-provision their devices, work remotely, and remain secure by applying the latest Windows Updates. But what about user’s data, files, and applications that they require to be productive? Moving to the cloud is a common goal for many organizations, though practical realities can make this a gradual process. Legacy technology, operational constraints, complexity, and other challenges can hinder adoption. While the goal might be to migrate all data to cloud-friendly repositories such as SharePoint Online and OneDrive, and transition applications to SaaS solutions, these migrations don’t happen overnight. In many cases, data may remain scattered across internal servers and on-premises repositories, creating scenarios where cloud-native devices still need to connect to these resources. Accessing on-premises resources What happens when you take a cloud-native device and try to access an on-premises resource such as a file share? Similarly, what about access to an application that is located on-premises? While these are just two examples, they can be used interchangeably in this scenario since the process of getting access is the same, regardless of apps or files. This is a topic that is raised (and often misunderstood) when discussing the transition of Windows devices to the cloud. Cloud-native devices were designed to take this scenario into account and have seamless access to on-premises resources. Note: This assumes you have line-of-sight to an Active Directory Domain Controller and that your on-premises resources, such as file shares and applications, use Windows authentication. Like a domain-joined device, a cloud-native device won’t have line of sight by default unless it’s physically on-site (for example, in a corporate office). If you require this functionality, you may need to use a VPN or Zero Trust Network Access (ZTNA) solution to provide this connectivity to on-premises resources. More on this later, when we touch on Microsoft Entra Global Secure Access. Legacy applications and authentication When people talk about legacy applications in this context, they typically mean apps that can only do legacy (NTLM or Kerberos) authentication with Active Directory. The good news is that for users synchronized using Microsoft Entra Connect Sync, cloud-native devices can seamlessly authenticate using NTLM and Kerberos just like domain-joined devices. When an on-premises domain account is synchronized to Microsoft Entra ID via Microsoft Entra Connect Sync, Windows uses details from Microsoft Entra ID, such as the source Active Directory domain name and the user’s User Principal Name (UPN), to locate a Domain Controller the same way an Active Directory domain-joined device does. If the user has signed into Windows using a password, Windows sends the on-premises domain information and user credentials to the Domain Controller to obtain a Kerberos Ticket-Granting Ticket (TGT) or NTLM token, based on the protocol the on-premises resource or application supports. From that point onwards, the TGT is used to get session keys that grant access to resources. Refer to How SSO to on-premises resources works on Microsoft Entra joined devices for additional details on how this process works. Note: Windows 11, version 24H2 and later releases have removed the NTLMv1 protocol as part of Microsoft's broader initiative to phase out NTLM. Refer to the Microsoft support article on Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 for additional details. Windows Hello for Business Passwordless authentication mechanisms such as FIDO2 and Windows Hello for Business are a cornerstone of Microsoft’s security vision. Adopting these authentication methods delivers stronger security and better, simpler user experiences. Windows Hello for Business provides phishing-resistant credentials as required by some security guidelines such as the Australian Cyber Security Centre ‘Essential Eight’. If you’re not already doing so, deploying cloud-native devices is a great opportunity to start using Windows Hello for Business, especially since it’s enabled by default on these devices. Windows Hello for Business is also a feature which results in a win-win scenario by enhancing security for IT, while also improving the user experience. While enabling Windows Hello for Business is a simple process, there’s some additional configuration required to enable single sign-on to on-premises Active Directory authenticated resources, and this is where we sometimes see customers running into issues. If username and password work successfully to access an on-premises resource, but Windows Hello for Business credentials don’t then ensure that you’ve setup Cloud Kerberos trust to enable single sign-on. Cloud Kerberos Trust removes much of the complexity once associated with configuring Windows Hello for Business, greatly simplifying the deployment process. When signing in with Windows Hello for Business, the device uses a partial Kerberos TGT issued by Microsoft Entra ID to obtain a full TGT from Active Directory, which in turn is used to get session keys to access resources. Refer to Microsoft Entra join authentication to Active Directory using cloud Kerberos trust for additional details. Zero Trust and modern connectivity On your Zero Trust journey, if you need to provide access to on-premises applications and services, consider replacing your traditional VPN with a modern solution, enabled by Microsoft Entra Private Access. Doing so will help you ensure secure, fine-grained access to private applications and resources, without exposing your full network - aligned with Microsoft’s three Zero Trust principles: verify explicitly, enforce least privilege, and assume breach. Review Zero Trust and Cloud-Native Windows for a deeper dive into this topic. On the subject of Zero Trust, did you know that Microsoft has developed a Zero Trust Workshop? By adopting Zero Trust, your organization can enhance its security posture and reduce risk and complexity while improving compliance and governance. Navigating the complexities of modern security is challenging and a Zero Trust strategy is the first step in providing clarity and direction. The Zero Trust Workshop is a guided framework to help you translate your Zero Trust strategy into actionable implementation steps which track your deployment progress and align with Microsoft recommendations. We’ve had many customers leverage the workshop to supercharge their Zero Trust journey and realize the full value of their existing security investments. The workshop can be run self-guided or in collaboration with your Microsoft account team or a partner and is vendor agnostic. Key takeaways If you aren’t already provisioning new Windows devices as cloud-native, check out Set up and configure a cloud-native Windows endpoint with Microsoft Intune and Cloud-native Windows endpoints: Begin by beginning to get started with a cloud-native Windows proof of concept today. Cloud-native doesn’t mean cloud only, these devices get the benefits of being cloud-first while maintaining the backward compatibility needed to access on-premises resources when necessary. Modern identity solutions such as Microsoft Entra ID, Windows Hello for Business, and Zero Trust Network Access can simultaneously enhance security and user experience. Be sure to check out our Zero Trust Workshop to help you plan and implement these and other technologies as part of your Zero Trust strategy. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!
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.
