Setting up Microsoft Tunnel to control access to Microsoft 365 mobile devices

Defining The Microsoft Tunnel Project Guidelines

In a recent project, my client defined the following requirements which we needed to address:

• Do not allow users to access the organization’s Microsoft 365 tenant from any external network.
• Monitor and control all traffic accessing Microsoft 365, including mobile devices.

Ultimately, they only wanted authorized users and devices to access their Microsoft 365 tenant. This limits the mobility and modern workspace benefits of Microsoft 365, but my client wanted to implement this approach for an undisclosed reason. I do need to add a disclaimer that Microsoft warns against this kind of configuration as it will impact its overall performance.

After some discussion and exchange of ideas, we settled on a solution that would use the following two components from the Microsoft 365 suite:

• Conditional Access – implement a rule to only allow access to the tenant from the client’s on-prem network which includes LAN, WAN, and their managed network.
• Microsoft Tunnel –tunnel all access from mobile apps (to Microsoft 365) via the client’s network using the per-app VPN.

The only drawback of the solution is that the client cannot use Intune MAM because using a per-app VPN requires mobile devices to enroll in Intune MDM.

You may wonder what browser access to use. The client decided to go with Defender for Cloud App, which I will not discuss in this article. Instead, I focused on how to implement the Conditional Access and Microsoft Tunnel components to fulfill the client’s requirements.

Figure 1 summarizes how the solution works after implementing the restrictions.

Part 1 – Conditional Access

To control user access from unauthorized locations, we must first define the location’s internet-facing IP address as a Network location in Azure AD (Figure 2). This could be one or more IP addresses and the range depends on the network configurations. In my client’s case, they enforce all internet access to route via HQ so that it would be a public IP of the HQ. However, if your case is internet access routing directly from each office, put all the IPs here. Conditional Access uses the source IP of a device to determine if the user is accessing it from a trusted or untrusted location.

Make sure you define either a specific IP (i.e., /32 netmask) or a range of IP (i.e.,, /29 netmask) and specify if those are trusted locations. You can refer to Microsoft’s Documentation for the definition of a trusted location, and consider if you should mark the location as trusted. The Conditional Access condition filter uses the trusted location flag to allow access from multiple trusted locations instead of adding the locations one by one, as shown in Figure 3.

Before applying the policy, make sure to check if you need to add any additional filters for specific device platforms or client apps. This is often necessary so be sure not to skip this step. For example, we want to block all access from external locations except through the browser.  Remember to exclude browser from the Client Apps section as that will be handled by the Defender for Cloud Apps policy.

When you are implementing the CA policy in your tenant, make sure you add exclusions for administrator user accounts. Otherwise, you might lock yourself out from azure AD.

Part 2 – Configure Microsoft Tunnel

Next, we install and configure Microsoft Tunnel. To set up the Microsoft Tunnel gateway using the Docker image provided by Microsoft, refer to Microsoft’s documentation. In this section, I explain some key settings and tips for this specific client implementation.

Microsoft Tunnel and DLP Gateway

One reason the client wanted all mobile traffic to travel via their network instead of going directly to Microsoft 365 is that they wanted the traffic to go via their on-premises DLP gateway (i.e., web proxy). This allows them to scan, log, and block the traffic (if needed). To implement the solution, you must modify the configuration profile assigned to client devices (Figure 5) to include the proxy URL or the PAC script (aka automatic configuration script).

Speaking of the client app required, note that at the time of writing (July 2022) Microsoft announced that the Microsoft Tunnel Standalone client app is no longer supported and is being replaced by Defender for Endpoint app (for both iOS and Android). If you have an existing implementation, you should plan to make the swap to Defender for Endpoint to make sure Microsoft Tunnel continues working. You can refer to Microsoft’s documentation for the update on this deprecation notice.

As part of the Microsoft Tunnel setup, the organization also wanted to control the traffic so that the host running the MS Tunnel Gateway Docker image could separate the traffic, and all internet traffic would travel via their proxy. Refer to Microsoft’s documentation for details of the Docker setup.

Figure 7 shows the design we implemented for the host to run the docker image. While our client wanted to use separate NICs, it is perfectly fine to have only one NIC on the host. Having two NICs allowed better control over the traffic flowing to the network.

MS Tunnel Client IP Address

Originally, we planned to assign a routable IP range to the Microsoft Tunnel endpoints. However, after checking with Microsoft Support, we concluded that we could use the 169.254.0.0/16 IP range instead of a private routable IP range. This is possible because the assigned IP range is only used between the Microsoft Tunnel Gateway and mobile devices. All traffic leaving the Microsoft Tunnel Gateway is through NAT, so the traffic appears to come from the Microsoft Tunnel Gateway host instead of the endpoint.

Figure 8 shows how we configured the IP address range in the Microsoft Tunnel Server Configuration.

If you cannot find the Tunnel tab, you may have incorrectly assigned the VPN profile assigned to the client, or the Defender app is not yet configured properly. Refer to the Microsoft documentation for a detailed guide on how to configure each client.

Split Tunnel and Per App VPN

Here are some important parameters to remember regarding the use of Split Tunnel in Microsoft Tunnel:

• iOS only supports Split Tunnel or per App mode for the Microsoft Tunnel traffic (you cannot have both).
• Android supports Split Tunnel and per App mode at the same time.

In this project, we decided to keep it simple. All selected apps (all Microsoft 365 apps and some others, like Salesforce) would start the per-app VPN when the app started and direct all traffic to the Microsoft Tunnel. This allows a consistent experience across platforms and is more efficient for the Microsoft support team to support the end users.

It is also worth noting that the location for the per-app VPN assignment is different for iOS and Android apps. iOS is located on the app setting page, whereas Android is on the VPN profile page.

If you configure Microsoft Tunnel and related apps correctly, when you start an app configured with Per-App VPN (Microsoft Edge in my case) on an iOS device, you should see the VPN icon displayed when the app is in the foreground. This means network traffic from that app is routed through the Microsoft Tunnel and routing via the on-premises DLP gateway to the internet.

Final Thoughts

In this article, I explain how to use different Microsoft technologies to meet client requirements. The client is happy, everything works, and that’s always the end goal for a successful project.