> Поменял Front end FQDN на AWG и AADS имя которое ввожу в браузере и которое настроено на reverse
> proxy.
Вы бы поточнее писали где и что точно вы меняли, особенно по чести AAWG.
Кроме настроек внутри самого AAWG надо еще и в Managemebt поменять, как я писал выше:
В Equinox management:
Settings/Devices/User Portal/General/Frontend FQDN = fqdn, которым закрыт интерфейс SBC

> На AWG Application,SIP и тд для всех интерфейсов изменилось в CN имя на имя которое ввожу в браузере.
> Также изменилось и на AADS.
>
> Далее открыл Wireshark и увидел что браузер больше не ломится напрямую на AWG, а ломится через
> reverse proxy.
> Но осталась проблема что он пытается подключиться по 443 порту к Equinox Managment. Я предполагаю что
> он берет эти настройки в AWG в разделе подключения к Equinox.
>
Нет, AAWG берет это из Equinox Management:
- Settings/Devices/User Portal/General/Frontend FQDN - когда запрос ему свалился через внешний интерфейс SBC (т.е. пришел на 8444 порт)
- Settings/Configurations/Service FQDN - когда запрос пришел через внутренний интерфейс SBC (т.е. пришел на 443 порт)
> На reverse proxy для internal интерфейса я использую сlien profile который использует сертификат
> CN=fqdn internal интерфейса, SAN=имя которое ввожу в браузере для подключения к конференции и fqdn
> internal интерфейса. Правильно ли я сделал? как сделано у вас?
>
Это вообще не очень важно, главное, чтобы TLS поднялся, а для этого достаточно, чтобы внутри все сертификаты были от SMGR (от общего СА).
> И что нужно настроить в AWG чтоб браузер не лез напрямую на Equinox, а подключался через reverse
> proxy??
>
Выше написал.
> Работает по прежнему только если у клиента стоит Root сертификат SMGR
Ну, вы уберите у него SMGR сертификат и посмотрите трейсами. на каком этапе все разваливается (т.е. на какой URL он шлет запрос, еэто можно посмотреть в Client Hello в расширениях SNI)