Сервер RPC недоступен при попытке повысить уровень контроллера домена. Открытый брандмауэр

Вот уже несколько дней я ломаю голову над этой проблемой.

Это краткая схема нашей инфраструктуры:

Наш основной контроллер домена работает в гипервизоре в нашем центре обработки данных. Перед запуском в нашу сеть MPLS есть два стека межсетевых экранов (Fortigate FG200D и pfSense).
Новый контроллер домена работает на «голой» установке на одном из наших сайтов, подключенном к MPLS, а также за двумя уровнями межсетевых экранов (Fortigate FG100D и pfSense).

Оба сервера работают под управлением Windows 2012 R2 и оба обновлены. Существующий контроллер домена будет называться DC-AD и новое будет RNS.

Я также отключил оба брандмауэра Windows и сделал позволять все в наших межсетевых экранах между двумя DC (по крайней мере, DC (DC-AD) и i-would-like-to-be-DC (RNS)).

Вот результаты сканирования Nmap:

От RNS в сторону DC-AD:

От DC-A в сторону RNS:

Я перепробовал все, что мог придумать, или все, что смог найти в Интернете, но большинство проблем связано с заблокированными портами в брандмауэре.

Это не все обязательные порты AD.

TCP и UDP 389
TCP 636
TCP 3268
TCP 3269
TCP и UDP 88
TCP и UDP 53
TCP и UDP 445
TCP 25
TCP 135
TCP динамический
TCP 5722
UDP 123
TCP и UDP 464
UDP динамический
UDP 138
TCP 9389

У меня есть этот список Вот; есть таблица, объясняющая, для чего AD использует каждый порт.

Я нашел другую статью предложил эти порты только для dcpromo:

TCP 3269
TCP 3268
TCP 389
UDP 389
TCP 636
UDP 636
UDP 500
UDP 4500
TCP 135
Случайный TCP 1024 - 65535, 49152 - 65535²

Итак, после запуска PortQueryUI я обнаружил, что несколько портов нужно отфильтровать, несмотря на то, что у меня были разрешены все правила между этими двумя хостами.

Я пошел дальше и все сделал tcpdump-d и обнаружил, что один брандмауэр имеет неправильное правило, из-за которого некоторые порты фильтруются.

После исправления этого правила dcpromo нормально работал.

Спасибо всем, кто мне помог!