Платформа фильтрации Windows, отбрасывающая соединения SQL Server

Я исследовал проблемы соединения между моим веб-сервером (Web01) и сервером базы данных (Database01). Моя текущая настройка:

Web01 - две сетевые карты, одна внешняя (защищенная от огня), одна внутренняя (не защищенная от огня).
Database01 - та же конфигурация, что и выше.

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

WEB01: A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)

или же

WEB01: The wait operation timed out

Это не согласуется, хотя они более вероятны, когда я выполняю сканирование (через Xenu) на Web01 для сканирования через новый веб-сайт.

На Database01 я определил серию сообщений от платформы фильтрации Windows:

DATABASE01: The Windows Filtering Platform has blocked a packet.

Исследуя это, это тихий фильтр предотвращения сканирования портов, встроенный в брандмауэр Windows. Эта функция работает независимо от того, что профиль Private (для частного сетевого адаптера) отключен.

Целью этой функции является перехват запросов на порты, к которым не подключен слушатель, и отклонение пакета.

Проблема в том, что рассматриваемый порт является портом сервера SQL по умолчанию, 1433 и sql сервер слушает.

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

Другие комментарии / возможные проблемы / примечания:

• Я использую Entity Framework с Autofac, и мой контекст использует область действия каждого запроса. Это должно гарантировать, что соединения закрываются и удаляются в конце каждого запроса, но внутренне это реализует модель единицы работы, в которой я надеюсь, что соединения открываются и закрываются для каждой пакетной операции, поэтому не должны ждать окончания любые потенциально длительные запросы.
• Конфигурация пула базы данных для ASP.NET не изменилась, поэтому время жизни соединения и размер пула соединений по умолчанию установлены.
• Первоначально в строке подключения было указано имя сервера, поэтому экземпляр по умолчанию: server=database01, но чтобы устранить любые потенциальные проблемы со службой браузера сервера Sql, я изменил строку подключения на server=tcp:database01,1433 для принудительного использования TCP-соединения используется (чтобы он не беспокоился о совместной памяти или именованных каналах), и точно указали порт (поэтому ему не нужно сначала запрашивать службу браузера, чтобы идентифицировать правильный порт).
• Database01 действует как принципал для зеркального отображения базы данных (как часть решения для зеркального отображения с двумя серверами с автоматическим переключением при сбое, Database02 в качестве партнера и Web01, работающий с SQL Server Express в качестве свидетеля). Я отключил зеркалирование целевых баз данных, и проблема все еще возникает.
• Я подтвердил, что sqlserver.exe слушает в порту 1433 с использованием netstat -anob -p tcp команда и может видеть его следующим образом:

netstat -anob -p tcp

TCP    0.0.0.0:1433        0.0.0.0:0            LISTENING      1896
TCP    192.168.3.2:1433    192.168.3.2:49274    ESTABLISHED    1896

В приведенных выше результатах 192.168.3.2 - это частный IP-адрес для Database01, а 192.168.3.1 - это частный IP-адрес для Web01, причем внешний порт 49274 динамически назначается пулом соединений ASP.NET.

Я пытался устранить как можно больше, но я все еще не могу определить корневую проблему:

Почему брандмауэр Windows отбрасывает пакеты для прослушиваемого порта?

Web01: Windows Server 2012 R2 Standard 64bit

База данных 01: 64-разрядная версия Windows Server 2012 с пакетом обновления 1 (SP1) для SQL Server 2012