Can't access SQL Server 2012 on virtualized environment outside LAN


Host: OS X 10.8.5 (Mountain Lion)
Virtual Machine Application: Parallels Desktop 9
OS on VM: Windows 7 Ultimate SP1
DB Manager: SQL Server 2012 Standar


SQL Server Instance canĀ“t be connected outside LAN, all computers in the LAN can access without any problem the SQL Instance that is listening @ 1433 Port.

When trying to connect with the Public IP forwarding 1433 port to VM the connection is refused.

Actual Configuration:

-Router forwarding the 1433 port to the VM
-Virtual Machine configured as Bridge using "Default Adapter"
-Windows 7 Firewall disabled
-SQL Server all protocols enabled (named pipes & tcp/ip)
-SQL Server TCP-IP protocol set "IPALL 1433"
-SQL Server Listening "any 1433"
-SQL Surface Area configured to ACCEPT remote connections
-SQL Server Browser Enabled and running

Alternate configuration already tested:

With Parallels Desktop alternate config.
-Virtual Machine configured as "shared connection"
-Ports Exception created to forward 1433 port to the Virtual Machine

With SQL Server listening on 6789 port
-Router forwarding 6789 port to VM IP
-VM configured as Bridge
-SQL Server configured to listen at 6789 Port


1.- With ALL configuration the SQL Server Instance can be acceded without any problem trough the LAN

2.- With ALL configurations the SQL Server Instance connection is refused trough Public IP


1.- If try with SSMS connect to then success
2.- if try with SSMS connect to 187.136.XXX.XXX then fail

Could you please help me to solve this?

Thanx in Advance!
Who is Participating?
x-menConnect With a Mentor IT super heroCommented:
do a tracert to check network routing , and a telnet 187.136.XXX.XXX 1433 to check connectivity.
David ToddConnect With a Mentor Senior DBACommented:

If you can find an old copy of SQL 2000 install media, on there is a small executable that isn't installed normally. The process to install is copy the file and rename the exertion to exe.

The file is odbcping.

It works in a very similar manner to the network ping.

It takes arguments of the server name or DSN entry, username and password or trusted security.

It can quickly validate connectivity to SQL without having to start an application or SSMS or whatever.

I've used it heaps to check connectivity through firewalls etc.


PS You haven't said if you are using a named instance or a default instance of SQL. Named instances don't listen on 1433 - the SQL Browser does that; there is another port which SQL is listening on, and this is dynamic unless you fix it. Dynamic in that it possibly changes each time SQL starts.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.