2

I'm trying to connect to a SQL Server from outside the LAN, so I opened port 1433 (default SQL Server port) in the firewall. On the server side I'm listening with Wireshark and I can listen ping (filtering by icmp or ip address) from ip X but nothing about telnet on 1433 or other ports (filtering by ip or by tcp / 1433). Network administrator cannot see my tcp traffic through the firewall too.

Can anyone help me?

Thanks.

sr.u
  • 21
  • 5

3 Answers3

1

(Second edit: if your network administrator on the server's LAN router side can't see any traffic coming to the router, then clearly the traffic is being blocked elsewhere: maybe in the client's LAN (is your client also behind a NAT?) or anywhere in between. Anyway I think VPN tunnel is the best approach to solve your problem)

(Edit: Keep in mind opening the database's port to the internet is not usually the best policy, better establish a VPN or at least filter the port to allow ONLY the ips who access it, like your webserver's, for example)

How did you bind the port? Is not a question of opening, it's about binding the router's incoming connections to port X (for example 1433), to port 1433 of the server lan's ip.

Besides there's the possibility any middle network is blocking the traffic before it reaches the router. Try changing the connection port in the router to, let's say 80 for example, IF it is free, or any other commonly non-blocked port.

Other probable reasons for your traffic being blocked may be traffic being blocked by type (traffic can be restricted by protocol in any/all ports, check also that) in the LAN's router or anywhere between the client outside the LAN and the router, in which case there's not much to do, but still you can set up a VPN tunnel to simulate a local connection, depending on your router's support for it (or you can also set it up on your server: check http://openvpn.net/).

Also check the server is not blocking connections coming from the router's ip address (sometimes it happens, but you should be able to see that on wireshark, I think)

Also http://progrium.com/localtunnel/ provides a free very easy to set up service to temporarily expose your server to the internet through a random generated subdomain link, it seems less safe, but still safer than opening/redirectig the port in the router without filtering...

NotGaeL
  • 277
  • 1
  • 3
  • 14
  • The firewall is filtered by ip and the binding it's done by our housing provider. Anyway i can access to other servers in the same subnet (port 80, there're webservers listening). The network administrator was listening in the firewall but he didn't see any traffic with destination to my server. I will try at least VPN solution. –  Dec 05 '11 at 11:49
  • All right, then it must be the traffic being block by the client side LAN's router or the client's firewall (if any installed) or just somewhere between networks (not much to do about that). Anyway, to throw a VPN link between your client and server or server LAN's router is pretty much straight forward but let me know if you've any trouble with it: I'll try to help if I know how. – NotGaeL Dec 05 '11 at 12:16
0

This may be a completely different issue, but it came to me today that maybe you haven't properly configured your my.cnf mysql configuration file to bind the mysqld server to the server's LAN ip address instead of the local loopback address, which is the setting by default. Your my.cnf file (usually located in /etc or /etc/mysql or /var/mysql) should look something like this:

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 1433
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/English
bind-address    = 192.168.1.21 #this is the server's LAN ip address!!
...
.....
.......

Hope this helps, in case you still haven't been able to solve your problem.

NotGaeL
  • 277
  • 1
  • 3
  • 14
0

After some testing I realized that the packet was lost between our firewall and the destination because the university source network blocks traffic for port 1433.

Thanks!

sr.u
  • 21
  • 5