July 18, 2007 at 9:32 am
I have a named instance of SQL Server that I'm trying to connect using Enterprise Manager from a webserver behind a firewall. Ports TCP XXX and UDP XXXX were opened bi-directionally as mentioned in the kb article referring to the bug:
http://support.microsoft.com/kb/318432/
I can connect when I create an alias that specifies the port that SQL Server is listening on, or specify the port number in the connection information. But I don't want to have to do this as the application seems to be having a problem with it. What else needs to be done in order to allow a connection through a firewall without having to specify the port number? Also, when I register a SQL Server via EM it is able to locate the specific named instance even when an alias isn't configured. What does EM use to scan the network for available SQL Servers?
July 18, 2007 at 11:04 am
EM queries UPD Port and from there retrieves the active instances, then it uses the Port in the "connection string"
Cheers,
* Noel
July 19, 2007 at 7:55 am
Are you allowing TCP on SQL server's port number to pass for the cluster node's IP address? The article states that the UDP service returns the physical node address instead of the virtual server's address.
I think you would need to allow the TCP traffic across for all the physical nodes as well as the virtual instance. It would probably be better to use the client network utility, however.
July 19, 2007 at 8:17 am
It does sound like udp/1434 is not going through on both sides. Can you have a network analyst do a network capture looking specifically for that?
K. Brian Kelley
@kbriankelley
July 31, 2007 at 10:48 am
An update. The application support vendor simply needed to specify port 1433 as stated in the KB article mentioned in the beginning (Servername\instance, 1433). All works well. However, you are right in that it doesn't seem to be allowing 1434 to be going through on both sides. The FW rule is bi-directional and open on the entire network, not just for specific IP's. When we looked at what was being dropped on the FW it showed various high level port numbers.
July 31, 2007 at 12:58 pm
I overcome these issues in 2 ways:
1. I create a Client Network Utility alias with TCP/IP as a protocol and uncheck "Dynamically Determine Port". I specify the port number explicitly whatever it is: 1433 or another port that SQL Server Named instance is using.
OR
2. If they allow port 445 Named Pipes, then I create a Named Pipes Client Network Utility alias
Regards,Yelena Varsha
July 31, 2007 at 1:48 pm
If you are specifying a default instance, than the port 1433 doesn't need to be specified. The client should try to connect to that port by default. If the port ISN'T 1433, then the port has to be specified.
For a named instance, unless you specify the port, the SQL Server Listener Service (udp/1434) is crucial. So if it was blocked, even if the named instance was told to listen on 1433, it wouldn't know to try that by default.
That said, either specifying the port in the connection string or setting a client alias like Yelena indicates both work well and I've done both. I will say, though, that if you ever come across named pipes as an option (tcp/445) for an Internet-based connection, someone needs to wake up the security folks. For internal (trusted) networks, I've done the same thing as Yelena and used aliases like this, I just want to make sure someone else reading the thread doesn't say, "Hey, named pipes, I'll ask for that!"
K. Brian Kelley
@kbriankelley
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply