Introduction

After the initial setup of Microsoft Tunnel, or when troubleshooting connectivity issues, the first thing to verify is whether the public endpoint is actually reachable. Before looking at logs or diving into the Intune portal, three quick checks from an external machine will confirm the network path is working end to end.

• Before troubleshooting logs, verify the basics from outside the server
• Three checks that cover the full path: DNS, port, and keep-alive
• If DNS or port fails, looking at agent logs is a waste of time – fix the network path first

Three Checks

1. DNS resolution – confirm the tunnel FQDN resolves to the expected public IP
2. Port connectivity – verify the tunnel port is reachable over TCP
3. Keep-alive response – the tunnel server returns I am still alive on its HTTPS endpoint

# DNS
Resolve-DnsName -Name tunnel.example.com -Type A

# Port (default 443, or a custom port)
Test-NetConnection -ComputerName tunnel.example.com -Port 443

# Keep-alive
Invoke-WebRequest -Uri "https://tunnel.example.com:443" -UseBasicParsing

Why this order matters:

• DNS must resolve before anything else works
• The port must be open before clients can connect
• Keep-alive confirms the tunnel server process is actually running – not just the port being open

The keep-alive endpoint: Microsoft Tunnel responds with plain-text I am still alive when you hit the root HTTPS endpoint. That string is the confirmation that the tunnel server process is up and responding.

If the port is open but the keep-alive fails from outside, the cause is not always the server process!

If you have a load balancer or an additional firewall layer in front of the tunnel server, those can pass the TCP handshake (port appears open) but block or fail to forward the HTTPS request. Always verify the keep-alive from both outside and from within the server itself (curl -k https://localhost:<port>) – if it responds locally but not externally, the problem is between the client and the server, not the server process itself.

Note on testing the local firewall: curl against localhost bypasses the local firewall entirely – it goes through the loopback interface, which ufw does not touch. To actually verify that the local firewall allows inbound traffic, curl against the server’s own LAN IP instead:

curl -k https://x.x.x.x:<port>

If that responds with I am still alive, ufw is not blocking inbound connections on that port.