I'm no firewall expert, or a SQL expert, but I'm not going to let those things stop me handing out advice on how you should configure your firewall or SQL configuration! I recently ran into a problem with getting a SharePoint Server to communicate with the SQL Server on a brand new installation. I turned off the Windows Firewall on the SQL Server and everything worked fine. Now, while I did mention that I'm no expert on firewalls, I know enough to realize that keeping the firewall turned off is not the best approach.
Usually SQL Server communicates through port 1433. Looking at the server's firewall configuration I could tell that port was opened. So how come I still couldn't access the database from a remote machine? The Windows Firewall with Advanced Security management console allows you to turn on logging of dropped packets. By using this I figured out that my SharePoint server was trying to access port 61683. Well, OK, I opened up that port by creating a new Inbound Port rule for TCP traffic.
That did it, my SharePoint Server was able to chat away to my SQL Server and off I went on my merry way. But I couldn't rest easy at night. Why port 61683? My searches on the internet brought back no real references to that port number. So I searched the registry on the SQL Server for "61683" and lo-and-behold, there it was – TCPDynamicPorts buried deep under the HKLM\Software\Microsoft\Microsoft SQL Server hive. This led me to the MS Support article How to configure an instance of SQL Server to listen on a specific TCP port or a dynamic port.
Yes indeed, the SQL Server was using a Named Instance. It seems that the default configuration for this means that SQL searches for a free port number to make the named instance available on. This dynamic allocation of a port number is not great from a firewall configuration perspective. Luckily you can change the configuration to use a static IP address. Look up the topic How to: Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager) in SQL Books Online (here's the SQL 2008 link). You can then set the firewall on the SQL Server without fear that the port will change randomly the next time your SQL instance restarts.
One final note – from what I have read, your SQL firewall should also have a rule to allow access to the SQL Browser application. This is how remote computers can find out what port your named instance is on. Checking the SQL Server in my environment, there is a rule called SQL Browser that allows the application C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe.
