Платформа фильтрации 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. Эта функция работает независимо от того, что закрытый профиль (для частной сетевой карты) отключен.

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

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

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

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

• Я использую Entity Framework с Autofac, и в моем контексте используется по запросу срок службы. это должен убедитесь, что соединения закрываются и удаляются в конце каждого запроса, но внутренне это реализует модель единицы работы, в соответствии с которой я надежда соединения открываются и закрываются для каждой пакетной операции, поэтому не должен дождитесь окончания потенциально длительных запросов.
• Конфигурация пула базы данных для ASP.NET не была изменена, поэтому время жизни и размер пула соединений установлены по умолчанию.
• Строка подключения изначально просто указывала имя сервера, поэтому экземпляр по умолчанию: server=database01, но чтобы устранить любые потенциальные проблемы со службой браузера Sql Server, я изменил строку подключения на 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, 64-разрядная версия

Database01: Windows Server 2012 64-разрядная версия SQL Server 2012 SP1 Standard