Lessons learned deploying Microsoft Tunnel Gateway

Over the last couple of days I have successfully deployed Microsoft Tunnel Gateway. Using the newer Microsoft Defender app on iOS. There are a few lessons learned here, which you won’t find in the documentation.

  1. The “Supported Operating Systems” list is accurate, when you remove all the deprecations.
    The only two supported routes is CentOS and Redhat Enterprise. Don’t get bogged down with the wrong distribution. Also dedicate a VM to this role.
  2. You will need to define a route to the server running Tunnel Gateway.
    Defining a route to the server running the Tunnel Gateway is essential for seamless functionality. Without this route, clients may connect, but their data will go nowhere. The data will reach your servers, but the responses won’t make it back to the clients. To ensure a smooth and two-way communication flow, it is crucial to set up the appropriate routes for the Tunnel Gateway server. This way, your clients can establish a successful connection and receive responses effectively, guaranteeing a reliable and efficient user experience.
  3. When designating an internal host to check for the health portal, it is recommended to use HTTP for simplicity.
    Opting for HTTPS would require the addition of some root certificates to the deployment, particularly if the SSL is signed by an internal CA. However, it’s important to note that handling SSL certificates signed by an internal CA is beyond the scope of the documentation.
    To streamline the process and avoid complications, consider using HTTP for the health portal setup. This decision ensures smoother implementation and avoids the complexities associated with managing SSL certificates from an internal CA.
  4. Your clients connect you WILL get traffic flow, but right after the tunnel will drop.
    When your clients connect, traffic flow is established, but you may encounter a situation where the tunnel drops immediately after connection. This issue is often caused by a conflict between the internal network range specified in the server configurations panel and the server hosting the tunnel gateway’s internal docker BEP (Backend Pool) range.
    To resolve this problem, ensure that the internal network range specified in the server configurations panel does not overlap or conflict with the server hosting the tunnel gateway’s internal docker BEP range. By addressing this issue, you can maintain a stable and uninterrupted tunnel connection, providing a seamless experience for your clients.
  5. Trust the only port required is what you have specified in the server configurations panel.
    The only port required for the Microsoft Tunnel Gateway is the one you have specified in the “Server Configurations” panel in the portal. The documentation previously mentioned 443/tcp and 443/udp, but please note that UDP has been deprecated since the retirement of the Microsoft Tunnel app.
    To ensure proper functionality, make sure your outbound firewall has port 443 opened to allow communication with various Microsoft resources.
  6. How do I use this as a per app vpn. I can only seem to get Safari to work?
    To configure an app to use the tunnel, go into your iOS app list and select the app you want to send via the tunnel gateway. The configuration property is in Assignments; simply choose the VPN profile that has been created in the device configuration.
  7. Certificate Requirements, So you need a certificate, but there are many different combinations of attributes. So you can cheat here is the info.
openssl.cnf

[req]
req_extensions = v3_req
default_bits = 2048
encrypt_key = no
default_md = sha256
prompt = no
utf8 = yes
distinguished_name     = req_distinguished_name

[req_distinguished_name]
countryName = [Country]
stateOrProvinceName = [State]
localityName = [City]
organizationName = [Organisation]
commonName = [External.DNS.Name]


[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = [Internal.DNS.Name]
DNS.2 = [External.DNS.Name]


sudo openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr -config openssl.cnf

Send your server.csr to your windows PC and run

certreq -submit -attrib "CertificateTemplate:WebServer" server.csr

Follow the process to receive the certificate. Once you have the server.crt you need to append a base64 version of the full certificate chain to the file. Send it back to the Tunnel Gateway server and place the certificate and private key in the filesystem as defined in the documentation. Your file will need to look like the below example.

-----BEGIN CERTIFICATE-----
MIIHOzCCBSOgAwIBAgITTAAAAYgTOK4pNtgKAQAAAAABiDANBgkqhkiG9w0BAQsF
ADB/MRIwEAYKCZImiZPVLGQBGRYCYXUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAU
BgoJkiaJk/IsZAEZzzzXJlezzzBgoJkiaJk/IsZAEZFzzzpY2UxJDAikkshwuduq
...
2M4+WpuQMRE2SYEwr2iYb4s46vbL96ale+6qlUHE2zdCOs6eVf/XG4qZcWB8RPzB
bTndZRFJ2B3htcgPmXSd7peFrTZsqIFyCU2zKuoIMSYV096zryM5Tecy28dOhJ7H
jgJFZQWR+SwXz9g8zWWkn6jvsxY5NysvpZ+53Sjdbw==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIF8zCCA9ugAwIBAgIQcLNdGlZ0e6BJCkAvoQjm0jANBgkqhkiG9w0BAQsFADB/
MRIwEAYKCZImiZPyLGQBGRYCYXUxEzARBgoJkiaJk/IsZzzzgNjb20xzzzAUBgoJ
kiaJk/IszzzFgZjYXJleXMxzzzoJkiaJk/IsZAEZFgzzzzz2UxJDAiBgNVw82hsj
...
VgtrSxckbpAGnlMs5Pq6bMpzpBwIp+oB6F2y1/f2fhrbbV6oDH9ruDfq+N884Tbk
2JR8S7UAN3cxbs7Z9YS+8xfqMmcnqN62otV5xalFmbiegES0+/FeOluFFexPyEds
/AdwDnf3kCMrx+i+BJQOEgJ+LEStAjJtgwu3dKhjMlUVCXkb3gca
-----END CERTIFICATE-----

Hopefully these ramblings make sense,

Leave a comment