February 14, 2011 at 7:46 am
I have an odd issue with connection to 2 SQL 2005 instances. Each exist on a different cluster. For some reason I have to specify ",port#" in SSMS in order to connect while on VPN. I don't have specify port for any of the 2008 instances on these 2 clusters. Nor do I have to specify port# for any of the many 2005 stand alone servers we have.
Is there something on the server I can check into?
Any insight would be appreciated. Thanks/
February 15, 2011 at 6:54 am
Bump
February 15, 2011 at 1:57 pm
If the instance is on a cluster, that instance should have its own resource group which has a defined IP address and name. The cluster handles redirecting the request to the appropriate node.
If you have to specify the port for that instance, then you probably have a problem with the SQL Browser service not being able to resolve the port. Verify that SQL Browser is running on all nodes in the cluster.
If this is a stand alone system, verify that SQL Browser is running on that system.
If SQL Browser is running, the next thing to check is to see if port 1434 for that system is blocked on the firewall.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
February 15, 2011 at 2:07 pm
Jeffrey Williams-493691 (2/15/2011)
If the instance is on a cluster, that instance should have its own resource group which has a defined IP address and name. The cluster handles redirecting the request to the appropriate node.If you have to specify the port for that instance, then you probably have a problem with the SQL Browser service not being able to resolve the port. Verify that SQL Browser is running on all nodes in the cluster.
If this is a stand alone system, verify that SQL Browser is running on that system.
If SQL Browser is running, the next thing to check is to see if port 1434 for that system is blocked on the firewall.
Do you still suggest this knowing that at work, inside the network I do not need to specify port.
February 15, 2011 at 7:31 pm
If you have no issues connecting with the name inside the network, then you have a firewall issue on the VPN. Either port 1434 is blocked or that instances port is being blocked.
I would expect the servers ports are blocked if you can connect to other instances on other servers without having to specify the port.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
February 15, 2011 at 7:52 pm
Network engineers quotes when asked...
"As far as the VPN goes, there is no filtering going on in any way at any time"
"there are no firewalls between the VPN and the network and we aren't even using the VPN concentrator as a firewall. The client doesn't do any firewalling, either."
I thought I tried testing a port that doesn't work in 2005 on a 2008 instance and it worked. I can't remember so better test that again. I'll even test it with a working port from 2008 and see what happens.
February 15, 2011 at 10:48 pm
You may want to check the server for an address routing issue. Find out what your ip address is when on vpn and check with the network admin or sys admin for the server to see if the address or the range is being redirected in the server.
Good luck.
February 16, 2011 at 8:06 pm
Well...today assigned the port that doesn't work on the 2005 instance to a 2008 instance. I just connected from home(VPN) with NO port specified. This has me stumped. It appear that any port I use on the 2005 instance does not work. Including 1433.
February 16, 2011 at 8:19 pm
That is definitely weird - there must be something with that instances configuration.
Some other things I would check, but honestly I don't know if any of these would cause this kind of issue.
Check for any server aliases on the host machines
Check for any entries in the hosts file on the host machines
Check for any invalid SPN records for that instance
Double-check the port configuration for that instance. Is it a dynamic port or static port assignment? If set as a static port, try using dynamic.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
February 16, 2011 at 8:22 pm
Thought of another thing to check - verify that you have enabled both TCP/IP and named pipes in SQL Server Surface Area configuration.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply