The scenario is that this is a SQL Server behind a corporate firewall with your standard setup to allow only minimal outbound traffic and zero inbound. However, port 80/443 are open, per the usual allowance.

Has anyone tried, or is it possible to

  1. Connect to a remote machine port 80, say using Telnet.
  2. On the local machine, note the bound address and port [1], e.g. netstat
  3. Disconnect from telnet. Start port forwarder and listen on [1], mapped to SQL Server TCP/IP listener
  4. On remote machine, connect to SQL Server on [1]

What do you think? I just need to get some testing done and I don't want to move my huge database outside for this one-off. I am familiar with and have used UDP hole punching for NAT traversal, mainly for push to mobile phones, but am interested to know if this works with TCP as well.


I am open to other suggestions.

Network topology

  • 1
    Would this question be a better fit for Server Fault? (Just asking -- seems like more of a networking question than a SQL Server question.) – Jon Seigel Oct 26 '12 at 2:23
  • It could be, but maybe there are other options used by SQL Server dbas/programmers, so I'm testing the waters here first. – 孔夫子 Oct 26 '12 at 2:27
  • 1
    You need to use VPN or DirectAccess. There is more that just the IP issue, there is also security at play. do the right thing. – Remus Rusanu Feb 23 '13 at 8:05

I doubt that it's easy to do hole punching with TCP or switch the process connected to a port.

Try this for a reverse proxy through the firewall: http://www.dest-unreach.org/socat/doc/socat-gender.txt

This solutions relies on socat, a swiss-army-knife like network tool which can connect almost any two endpoints and is bidirectional, unlike netcat or the |-pipes in command processors. It should be available for Windows, too.

You can either use socat easily to forward a TCP connection, or in this case: Reverse the "gender" of it: You'll have two socats running, one on each side of the firewall. One continuously connects to the outside. On the outside, socat will wait for a connection from someone else. Only if he connects, the outside socat will accept a connection from the inside socat. Once the inside socat connects to the outside socat, it will connect to the SQL-server. Voila, you can connect from outside to the SQL-server inside, and from the point of the firewall and from the point of TCP the connection looked like it was actually from inside to outside.

To copy from the link:

1) Start the double client on the inside server // every 10 seconds, it tries to establish a connection to the outside host. // whenever it succeeds, it forks a sub process that connect to the internal // service and starts to transfer data

$ socat -d -d -d -t5 tcp:outside-host:80,forever,intervall=10,fork tcp:localhost:80

2) Start double server on the outside client // wait for a connection from a local client. whenever it accepted it, forks // a subprocess that tries to bind to the socket where the inside double // client tries to connect (might need to wait for a previous process to // release the port)

$ socat -d -d -d tcp-l:80,reuseaddr,bind=,fork tcp-l:80,bind=outside-host,reuseaddr,retry=10

This basically sounds like a reverse proxy. I was in a situation where I almost had to implement this in order to move SQL Server to a different data center in a 24/7 environment, but we used another method. Between discussions with the networking and ops teams, it should be possible but I didn't get to explicitly test it out myself to tell you my results.

SQL Server needs to get the requests on the port # assigned to it as far as SQLOL is concerned so I don't see why not, and there's an article written about doing this with a focus on the benefits of avoiding SQL injection at TechRepublic found here.

Basically it goes through the frequency/severity of SQL Server injection attacks and how a reverse proxy would first forward the requests from the web client to that device, then that device would send the request back after sanitizing it. In their topology diagram they had the reverse proxy box hitting the web server again then having it go to SQL Server, in this case we would have it directly connect to the sql server most likely.

Unless I completely misunderstood your question, that should solve it. You connect to a reverse proxy on port 80, the agent then forwards your request to SQL Server on your specified port (default port 1433).

  • Can you elaborate on that? Consider me as a normal corporate citizen with no access to the firewall. I can't install a reverse proxy on port 80 within the firewall (SQL Server side). I need to get from remote into SQL Server behind a NAT. – 孔夫子 Oct 26 '12 at 2:17

Can you not just RDP in on port 80 and do what you need to do as per: http://www.iteezy.com/change-rdp-3389-port-on-windows-2008-server/qc/10098


You can try using SQL authentication between servers. It works for me.

Your Answer

