Include the container bridge in Microsoft Tunnel address-conflict checks

Source facts

Microsoft Tunnel’s Docker and Podman containers use a bridge network to forward traffic through their Linux host. If that bridge overlaps a corporate network, the gateway cannot successfully route traffic to that network. The documented defaults are 172.17.0.0/16 for Docker and 10.88.0.0/16 for Podman. Microsoft provides procedures for changing them, but requires Tunnel Gateway installation before changing the bridge configuration. Microsoft Learn.

Applicability

Apply this review to the Linux container-host network for Microsoft Tunnel. Inspect the active runtime and bridge configuration rather than assuming the documented default is still in use.

DSE recommendation

Add the container bridge as its own entry in the gateway’s address inventory. Compare the actual bridge range with the corporate destinations that clients must reach. If a conflict is found, have the network and Linux owners plan the runtime-specific change through an approved maintenance procedure. Preserve the initial bridge and routing state, select an agreed nonoverlapping range, and follow the documented installation-order requirement. Do not paste the source’s example replacement address into a production design.

Verification

After an approved change, inspect the effective bridge configuration and test a named destination in the formerly conflicting network from an intended tunnel client. Also verify an unaffected destination to detect unintended routing changes. Keep the client address pool and container bridge results separate so a successful check of one is not recorded as proof of the other.

Official references

Microsoft Learn: Prerequisites the Microsoft Tunnel VPN for Microsoft Intune.