1

We have a SQL server that is hosted on AWS, the SQL server it not directly accessible on the internet, it relies on a NAT box to route traffic to it.

We are trying to set up a Linked SQL server from this server to another one outside of AWS, this requires the two SQL servers to talk to each other on port 1433 TCP.

The relevant sections from the iptable look like this:

target prot source destination

DNAT udp anywhere anywhere udp dpt:ms-sql-m to:172.10.10.10:1434

DNAT tcp anywhere anywhere tcp dpt:ms-sql-s to:172.10.10.10:1433

From our own testing we know that we can link any server to the one on AWS but not the other way around.

Does anything look wrong? The problem started occurring when our intfra engineer 'removed and added them same rules' Are there any clues in that? Is order relavent?

Using tracetcp we found the following:

Doing this command on the aws sql server 'tracetcp.exe 183.23.53.22 1433' where the ip is that of the other externally hosted server, it would get to the destination in 1 hop, but it would also do the same reguardless of any random ip address we tried.

enter image description here

Where as if we did the same command but on another other port other than 1433, it would hit the NAT box first and then do many hops

enter image description here

Improve this question

2 Answers 2

Reset to default
1

Check your iptables rules with iptables-save and re-post them. Verify that your DNAT rules have some method of excluding traffic originating from inside the network, for example -i <extif>, ! -i <intif>, or ! -s 172.10.10.10. I strongly suspect it is resending your packets back to the internal origin server.

Improve this answer
1
  • You are a legend
    – Dan
    Commented Mar 10, 2015 at 12:04
1

It might be that you have a running proxy on the port 1433 which can cause a behavior like you described. The proxy accepts the connection to the internal machine immediately and that's why you get such a short timed response of 2ms.

Also, a good indicator that your packets didn't leave your LAN is such a short reply time (1-4 ms). Try to check on your NAT box if you accidentally started any proxy process and if not, try disabling the DNAT rule for the port 1433 (tcp) to see if the issue persists.

Also, this statement "not directly accessible on the internet, it relies on a NAT box to route traffic to it" is contradicting, since the machine is accessible on the internet, but on a specific port, through which the NAT translation is being done, right?

If you really want to protect your service from the outside world, maybe it would be a smart idea to consider some kind of a VPN perhaps? Or if you want a more simple solution (but not as secure as VPN), you might just allow the access to that NATed port from the known remote IP address (which attackers can spoof in some cases).

Improve this answer
2
  • +1 for suggesting VPN. If using linked servers you really want your traffic to be done through an encrypted VPN. The overhead is negligible, and modern VPN tunnels are easy to set up even for a novice.
    – Reaces
    Commented Mar 7, 2015 at 12:37
  • You think it could be a proxy that only effects 1433? Seems like a long shot?
    – Dan
    Commented Mar 7, 2015 at 13:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .