Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

First off, apologies in advance for any misuse of networking terminology - I'm definitely not a networking guy.

I'm renting an instance from Amazon's cloud and want to have it connect to my SQL Server Express 2008 server that's in my apartment (on Win7). Problem is, that server is behind Comcast's NAT - that is, its public IP Address (say 24.130.X.X) is not the same as its private IP Address (say 192.168.X.X), and my macbook has the exact same public IP Address as my data server.

When I'm on the Amazon cloud instance and try to connect to the SQL server in my apartment, if I just try to connect to 24.130.X.X (the public IP), it doesn't work. This doesn't surprise me since I'm not sure how it could tell whether I'm trying to connect to my macbook or my data server, for example.

My question is: is it possible for me to connect to my data server through Comcast's NAT, using some more specific IP address than the generic public one? Obviously since it's Comcast's NAT, I can't modify it or do port forwarding or something.

Just in case it comes up, yes I've gone through countless articles on configuring SQL Server Express 2008 for remote access and I've added exceptions to the firewall. Thanks in advance for your help and patience.

share|improve this question

Generally it's not advised to open an SQL instance to the outside world, it's a serious security flaw in your system if it is enabled, although, you can try various things and workarounds to make it work.

My first answer would be port forwarding, but since you mentioned that it is impossible in this case, you could create a service (through tcp/udp/http whichever is the most convenient to you) and access you DB through this service. This is going to take some basic programming (not much of a hard job, more like physical programming).

The "lumberjack" workaround would be simply registering a dyndns or no-ip or similar account, install it and connect to you SQL server through it.

I'm pretty sure that there are a bunch of other solutions, but these are that came to my mind instantly.

Hope it helps

share|improve this answer
Lumberjack approach sounds promising - thanks so much for the suggestion (and apologies for the tardy reply) – Mike Monteiro Aug 15 '12 at 18:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.