"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Port 1433 is only the case if the sql server is the default instance. in the case of a named instance (SQLSERVER/InstanceName), the client first attepts to connect via udp to port 1434 to get the proper port number and then connects to that port. If you are using a firewall then you can set a fixed port for the named instance and then open both that port (tcp) and the udp 1434 port. You can also add an exclusion for sqlserver.exe I believe this article describes it well:http://www.mssqltips.com/sqlservertip/1929/configure-windows-firewall-to-work-with-sql-server/

However, your cluster complicates things with a known issue. When the client connects to the cluster ip on udp 1434, the server replies with a packet having the dedicated ip as the source address, causing the client firewall to drop the response as an unsolicited packet. There are three workarounds that I know of:
One, configure the client firewall to allow all inbound udp. This allows the client to correctly receive the port number to connect to for the named instance.

Or Two, configure the clients to connect to the host/port combination rather than the host/named instance. This eliminates the need for the udp lookup for the instance port.

Or three, give the server an additional IP and put the instance on that ip with port 1433 (using the sql server configuration manager as shown in the above article). Then you would need to configure clients to connect to this new ip rather than the old ip/instance combination. This also eliminates the need for the udp lookup for the instance port.