RDP: удаленное приложение не инкапсулирует трафик при подключении через сервер шлюза удаленного рабочего стола

У меня есть приложение для удаленного рабочего стола, которое было опубликовано сторонней корпорацией для одного из моих клиентов. Приложение удаленного рабочего стола подключается к серверу шлюза удаленного рабочего стола (RDGW), который перенаправляет запрос на сервер удаленного рабочего стола, где наименее используемый сервер отвечает на запрос и открывает приложение. Это отлично работает для большинства сценариев.

Сегодня я столкнулся с ситуацией (допустим, приложение было опубликовано для нового клиента), когда RemoteApp запрашивало у пользователя его учетные данные (домен \ имя пользователя и пароль) сразу после аутентификации пользователя и принятия сертификата для фермы RDS, mstsc.exe перестанет работать, не будет реагировать на кнопки отмены или закрытия, и его необходимо прекратить через диспетчер задач.

При устранении этой проблемы я обнаружил разницу в способе подключения RemoteApp к серверу шлюза RemoteDesktop. Во всех моих положительных тестовых сценариях трафик был полностью инкапсулирован в HTTPS между моим MSTSC и шлюзом сервера удаленных рабочих столов следующим образом:

Регистрация трафика для той же процедуры на одном из отказавших mstsc дала мне следующее:

Первый диалог (как он называется в NetMon) - это HTTPS-соединение с сервером RemoteDesktop Gateway (HTTPS, порт 443), за которым следует отдельное соединение RDP, который пытается подключиться к самому серверу RD через свой частный IP-адрес (я просто убрал его на картинке из соображений конфиденциальности и безопасности). Второе соединение в конечном итоге терпит неудачу, поскольку сервер удаленных рабочих столов не находится в том же месте / подсети, поэтому частный адрес недоступен для mstsc.

Сначала я подозревал, что клиентский брандмауэр проверяет трафик HTTPS, заменяя сертификаты, поэтому он может прервать успешное HTTPS-соединение с сервером RDGW. После отключения всех функций веб-фильтра на брандмауэре проблема все еще сохраняется. Я также пробовал маршрутизировать трафик через туннель OpenVPN, чтобы он полностью обходил брандмауэр, но, к сожалению, безуспешно.

Что могло заставить mstsc не инкапсулировать соединение rdp в трафике HTTPS, как при успешном соединении? Это какая-то запасная стратегия или просто ошибка? И что можно использовать в качестве расширенного устранения неполадок для удаленного приложения, поскольку оно не имеет ценных файлов журналов, а серверы RDS и RDGW не находятся под моим контролем?

РЕДАКТИРОВАТЬ (добавлен анонимный файл конфигурации):

redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
span monitors:i:1
use multimon:i:1
remoteapplicationmode:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:0
videoplaybackmode:i:1
audiocapturemode:i:1
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:INTERNAL-FQDN-SERVER-HOSTNAME.CUSTOMER.NET <!! EDITED FOR ANONYMIZE REASON
alternate shell:s:||name_of_remote_app_on_wts <!! EDITED FOR ANONYMIZE REASON
remoteapplicationprogram:s:||name_of_remote_app_on_wts <!! EDITED FOR ANONYMIZE REASON
remoteapplicationname:s:name_of_remote_app_on_wts <!! EDITED FOR ANONYMIZE REASON
remoteapplicationcmdline:s:
workspace id:s:INTERNAL-FQDN-SERVER-HOSTNAME.CUSTOMER.NET <!! EDITED FOR ANONYMIZE REASON
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.RemoteApp-EXT
alternate full address:s:INTERNAL-FQDN-SERVER-HOSTNAME.CUSTOMER.NET <!! EDITED FOR ANONYMIZE REASON
authentication level:i:2
prompt for credentials:i:0
negotiate security layer:i:1
gatewayhostname:s:external.gateway.ourcustomer.com <!! EDITED FOR ANONYMIZE REASON
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,Alternate Shell,RemoteApplicationProgram,RemoteApplicationMode,RemoteApplicationName,RemoteApplicationCmdLine,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
screen mode id:i:2
winposstr:s:0,3,0,0,800,600
compression:i:1
keyboardhook:i:2
connection type:i:7
networkautodetect:i:1
bandwidthautodetect:i:1
displayconnectionbar:i:1
enableworkspacereconnect:i:0
disable wallpaper:i:0
allow desktop composition:i:0
disable full window drag:i:1
disable menu anims:i:1
disable themes:i:0
disable cursor setting:i:0
bitmapcachepersistenable:i:1
audiomode:i:0
redirectposdevices:i:0
autoreconnection enabled:i:1
remoteapplicationicon:s:
shell working directory:s:
gatewaybrokeringtype:i:0
rdgiskdcproxy:i:0
kdcproxyname:s: