Tunnel Gateway

10 days and 10 tips for Microsoft Tunnel Gateway: Day 6

by

Free TLS Certificates with Let’s Encrypt

Microsoft Tunnel requires a TLS certificate that is trusted by the connecting clients. It doesn’t have to be publicly trusted – an internal PKI cert works fine, as long as you deploy the root CA chain to devices via an Microsoft Intune Trusted Certificate profile.

In a lab, that’s extra work you can skip. Let’s Encrypt is free, already trusted by every iOS and Android device, and you can have a cert issued in under 10 minutes.

Lab/testing use only. Let’s Encrypt certs expire after 90 days and with this approach renewal requires manual DNS interaction each time. Don’t use this approach in production. Use internal PKI or a commercial cert with automated renewal instead.

Prerequisites:

  • A public DNS zone you control, with the ability to create/modify TXT records
  • Sudo access on the Ubuntu Tunnel server
  • Outbound internet access from the server (to reach Let’s Encrypt and apt repos)
  • An email address for Let’s Encrypt expiry notifications

Read more…

10 days and 10 tips for Microsoft Tunnel Gateway: Day 5

by

When Tunnel Updates Fail

Updates to the Microsoft Tunnel containers can apparently fail mid-process. I’ve seen this on three different deployments where the automatic update pulled container images with SHA256 hashes that weren’t documented anywhere in Microsoft’s official release notes.

This left the agent container endlessly restarting. Here’s how I identified and fixed it without reinstalling.

Note: I’ve only encountered this on Ubuntu Server with Docker containers. I don’t currently work with Red Hat/Podman, so I can’t speak to that environment.

Read more…

10 days and 10 tips for Microsoft Tunnel Gateway: Day 4

by

Post-Installation Health Check

The Microsoft Intune admin center shows basic tunnel server status, but when I’m SSH’d into a server troubleshooting, I need answers faster.

This health check script shows everything in seconds. I run it right after installation to verify everything works, and whenever I’m troubleshooting to see what’s broken.

GitHub Repository: https://github.com/imabdk/Microsoft-Tunnel-Gateway

What it checks:

  1. Service and container status (mst-cli health + Docker/Podman container validation)
  2. Configuration files and sync status from logs
  3. Certificate expiration (warns if under 30 days)
  4. Recent errors in logs (last 30 minutes of mstunnel-agent, mstunnel_monitor, ocserv)
  5. Server configuration (routes, DNS, ports from admin-settings.json)
  6. Listening ports

Read more…

10 days and 10 tips for Microsoft Tunnel Gateway: Day 3

by

Automate Your Prerequisites

If you’re deploying multiple tunnel servers or rebuilding environments, save yourself the hassle and automate it. I’ve created shell scripts to handle all the prerequisites and configuration steps.

Available Scripts

GitHub Repository: https://github.com/imabdk/Microsoft-Tunnel-Gateway

  • setup-prerequisites-ubuntu.sh – System prerequisites and package installation (Docker, kernel modules, jq)
  • setup-auditing-ubuntu.sh – Configure audit logging for security compliance
  • setup-firewall-ubuntu.sh – Firewall configuration and rules setup

Read more…

10 days and 10 tips for Microsoft Tunnel Gateway: Day 2

by

Expand Your Readiness Checks

The official readiness script is a good start, but it has a blind spot in regards to checking for outbound connectivity: redirect chains. When an endpoint redirects to another domain that’s blocked, the script just throws “Error: not expected” without telling you what’s actually being blocked.

That’s why I built a custom diagnostic tool – to trace those redirect chains and tell you exactly which domain is causing the problem.

Read more…