Testing Microsoft Tunnel
VPN on Mobile Device is not something we want to do but it is something we have to do for legacy apps, when the following approaches are not possible:
- Migration of the app to a Cloud Service
- Integration of the apps in AAD
- Publishing with AppProxy (or F5 / Netscaler / …)
Apparently Microsoft is doing the same, because at the Ignite a VPN solution for mobile devices including conditional access integration was presented (rather unexpected for me).
Compared to other VPN solutions M365 Tunnel has these benefits:
- You have a full Conditional Access integration. This means you can use all available conditions (think of Compliance, Risk, MFA) for controlling the access to the VPN and use it as a part of your Zero Trust strategy.
- It’s included in the Intune licenses.
In addition to accessing resources in the data center, it can also be used to create a solution for apps that do not support Device Based Authentication, as we can then configure conditional access policies based on the IP addresses of the VPN gateway.
Microsoft Tunnel consists of the following components:
- Docker based VPN Gateways
- Tunnel Apps for Android and iOS
- Configuration portal in MEM
Simple setup in a Lab environment
For our lab, we only built a Linux VM with a 2-legged network connection. The external interface is directly connected to the internet, the internal one to the LAN. According to the documentation, the scenario can be easily set up redundantly and scalably in a production environment using load balancers. A placement of both interfaces in the perimeter area also seems very reasonable to me to ensure that only the really needed applications can be reached. (Zero Trust)
The solution only supports connections initiated by the end device. This has the advantage that all connections at the gateway are NATted and we only have to pay attention when selecting the address pool not to overlap with the address ranges used in the LAN. Routing is not necessary.
The ability to create sites and assign gateway servers and policies makes it possible to map more complex scenarios. For example, several data centers, different network zones or test and product environment, …
Here is the list of things we need for a PoC
- 1 x VM Linux incl Docker (we took CentOS)
- 2 NICs in the perimeter (internal / external)
- Public DNS entries and a matching public certificate
- Firewall rules INET->GW HTTPs
- Intune managed MDM Device (iOS/Android)
- VPN address pool for the devices (unrouted)
- Conditional Access Policies
- Ressource in the data center for initial testing
- An AAD integrated Cloud Service for initial testing
- Firewall rules GW -> ressources (LAN, INET)
Deployment of the VPN Gateway
The whole deployment procedure is really well described here in the Microsoft documentation. If you’re familiar with the deployment and configuration of Linux servers you will find all M365 tunnel specific there. (Ask your favorite Linux admin)
The tricky part are the certificates because you have to include the whole certificate chain in the configuration and your overall cert lifetime can’t be more than 2 years (really!) because apple is refusing all certs with a longer lifetime.
After the deployment it’s a good idea to make yourself familiar with the mst-cli.
Test devices
For testing purposes the usage of an Android Emulator is really handy. You just have to download the Android Studio and deploy the devices you need.
Creation of configurations
To give the solution the necessary flexibility, the configuration is broken down into the following components:
- server objects that represent the gateways and contain the entire configuration for the gateway. Later, only the Linux system that provides the Docker Service needs to be configured.
- Sites to group servers by location, network zone or stage
- The endpoints are configured using Configuration Profiles of the type VPN. Here you decide which apps use the tunnel and whether the VPN should be set up automatically (Always-on VPN). Unfortunately, both configuration and functionality are different on Android and iOS.
Conf iOS: https://bit.ly/33fMeBb
Conf Android:
- A Service Principal is created that allows us to use Conditional Access. It would have been nice if an Enterprise App would have been created here so we could use Group Based App Access and not have to block access with CA. There is still room for optimization.
For the lab setup we’ve configured:
- A server configuration incl. an unused address pool and a DNS suffix (the AD domain)
- A tunnel site configuration incl. the server config and a public FQDN for our Gateway
- A VPN configured for android incl. the tunnel site and the tunneled apps. For the demo use cases we’ve chosen Edge and File Commander.
- A Conditional Access Policy incl. the cloud app Microsoft Tunnel Gateway that enforces a Compliant Device as Grant Action. (the tenant needs to be provisioned before)
Test and Use Cases
For testing our deployment and demonstrate the capabilities of M365 tunnel we have implemented the following Use Cases:
- Access an internal Website with the Edge browser
- Access an internal SMB Share
- Access a file in OneDrive with PDF Expert
But before we go into the use cases, I would like to take up the introduction and clarify that a Micro VPN should never be the first choice — here are a few examples:
- Control web traffic with an OnPrem proxy
-> better choice: Cloud Proxies or Microsoft Defender for Endpoints - Access OnPrem Web Apps like SharePoint
-> better choice: publish them with an App Proxy - Access OnPrem SMB Shares
-> better choice: migrate your files to SharePoint Online / OneDrive
1. The internal website
If you can’t manage to publish your internal website with an App Proxy or you need a temporary solution you can make your internal web apps accessible via the VPN.
For me it sounds like a good idea to use a browser on the device exclusively to access the internal websites, since iOS does not support split tunneling.
2. The SMB share
Usually things do not happen in the ideal order in projects. So it happens that the rollout of devices managed with Intune should start before the file migration. If this means that users can no longer access folder structures, trouble is inevitable.
In our demo case we have accessed the SYSVOL share on a DC — and it just works! (if you have opened the necessary ports in the Firewall)
3. The Cloud Service without support for Device Authentication
Many companies have the requirement that certain SaaS services can only be accessed by managed devices and use conditional access to enforce this. (See my blogs on CA)
Because mobile devices access WebApps much more often through native apps than Windows, the issue of authentication is more important and must be done per app. There are 3 categories of apps:
- Apps with native SSO and device auth support (eg. the Office apps)
- Apps with support for the new iOS SSO extension (eg. Salesforce)
- Apps without SSO and device auth support
For the last category M365 Tunnel is our solution to solve this requirement, because:
- we can control which apps (tunnel config) on which devices (Conditional Access) can open the tunnel
- we can control that only devices accessing from the public IP of the VPN Gateway can access the Cloud Service (Conditional Access)
For our test we’ve enabled the access from Foxit PDF to a file in OneDrive.
If you’re using Android it is really important for this Use Case to not use Split Tunneling.
Monitoring
The possibilities for monitoring are already quite good from day 1 and have been improved by the last update. It is possible to interactively query which devices / users currently have a tunnel open and where there are connection problems. Since the update of October 12th a syslog integration is also available — so the logs can be brought to Azure Monitor and Azure Sentinel via an agent.
As with all components of M365 Tunnel, the documentation from Microsoft for the monitoring and the mst-cli is surprisingly good(for a preview)
What could be better in the future?
- AAD Integration as an Enterprise App to allow Group Based App Access.
- Support for multiple tunnel over the same infrastructure on the same devices because I’d like to control the access to Apps on a per App basis (client app or ressource).
- Monitoring Integration in the MEM portal or prebuilt Dashboards or Workbooks in Azure Monitor.
- Integration of Continuous Access Evaluation to revoke the tunnel access if a risk is detected.
