问题
I'm running into some odd behavior trying to configure a highly available remote desktop connection broker scenario. I'm using Windows 2016 and the SQL Server 2016 client connectivity tools (SQL Server Native Client 11.0).
During the configuration, it requires a SQL Server connection string, which I've triple checked as correct. When it configured, it does not find the SQL Server. I've isolated the problem to the Windows Firewall and here is what I've discovered:
Firewall service disabled: Works.
Firewall service enabled, but firewall turned off: Does not work.
Firewall service enabled, firewall turned on: Does not work.
Firewall service enabled, firewall turned on, exceptions allowing all traffic: Does not work.
This also seems to only affect using a named SQL Instance. If I use the default instance, there are no issues. With logging enabled on the firewall, I can see the following:
2017-09-06 13:28:01 DROP UDP 10.59.128.18 10.59.28.217 49577 1434 0 - - - - - - - SEND
If I run a capture on the Microsoft Network Monitor while trying this, it does not show ANY traffic on port 1434 with the firewall on and exceptions configured. If I disable the firewall service, the network monitor does show traffic on 1434.
One other test I did was reset the firewall to defaults and verify there are no denials taking places. I noticed a ton of dropped packets in the log, as expected. When add the allow all rules, all of those dropped packets are then allowed EXCEPT for the ones going through 1434. Every article I find regarding this explains opening up ports in the Windows Firewall, which is already done.
I also tried the connection string using the currently assigned dynamic port of the SQL instance and it worked, but that is not a solution as the dynamic port will change.
回答1:
I solved the problem by disabling the Named Pipes protocol on the SQL Native Client on the client machine.
来源：https://stackoverflow.com/questions/46105293/windows-firewall-dropping-packets