I have a clickhouse server running in my local network. I could access it through 192.168.0.96:9000 on the other machines in the same network.
However, after I forwarded the port 9000, and try to access outside the local network using (my IP) xxx.xxx.xxx.xxx:9000, I got a ERR_CONNECTION_TIMED_OUT. I couldn't figure out the issue.
The version I use is: 20.12.4.5, and
I already changed the etc/clickhouse-server/config.xml:
<!-- <listen_host>::</listen_host> -->
<!-- Same for hosts with disabled ipv6: -->
<listen_host>0.0.0.0</listen_host>
and the server does not have any firewall.
I scanned ip you provided with nmap and it looks like you have only port 8888 open.
Maybe you didn't configure port forwarding properly.
Related
I am trying to open access to my SQL Server from outside my network, but while my ports are open in my Windows Firewall and routed from my router, telnet can't connect.
To explain a bit more I have opened both TCP 1433 and UDP 1434 ports in my Windows Firewall to allow remote access to my SQL Server.
Ports seems to be properly opened in my windows firewall as both a telnet [local_server_ip] 1433 and SSMS can connect from a different computer within my local network.
When trying to connect from outside my network (using my external IP) Telnet can't connect (Connect failed).
In my router, ports are redirected (TCP 1433 and UDP 1434) and I also tried setting my SQL Server IP as DMZ but it did not went through. My other port redirection works properly so I don't think it comes from the router (for instance I have Emby as a media server, and I can access it from outside my network or use telnet to connect to the port opened for this service).
Am I missing a configuration in SQL Server configuration manager? For instance I had to manually set the TCP port in SQL Server Network Configuration > TCP/IP properties > IP Adresses > IPAll and set TCP Port as 1433
Or can it come from either my Windows Firewall (even though the inbound rules has similar characteristics as the inbound rule for my Emby server) or my router?
So locally it all seems to work, but from outside it does not? This does indicate your router NAT setting being an issue.
Just to point out, exposing an SQL Server to public internet is relatively insecure. Ideally you add a VPN to your local network and use that to reach the SQL server instead. Just to point out, I can imagine it could work, but you might want to rethink the setup.
I have to connect to a fresh SQL Server Express 2017 on a machine not part of my domain. I have configured
Mixed Mode Installation with sa with password
SSMS -> Server -> Properties -> Connections -> Allow remote connections
SQL Configuration Manager -> Instance "EXPRESS2017" -> TCP/IP: Enable and Active and Port 1438
Restarted the "SQL Server (EXPRESS2017)" service.
I now tried to access from a remote computer, and got a timeout. I then tried to connect from the local SSMS, which works without special settings, but when under options, forced "Protocol: TCP/IP" is set, with the same credentials as before, I also got a timeout.
So am I right that I can rule out the firewall or problems finding the instance, and everything points towards a configuration issue in TCP/IP protocol, or did I overlook some setting?
EDIT: I have disabled Windows firewall, and no other firewall is installed on the computer. I have restarted the computer. I also found this article about PortQry and had a check - locally:
C:\Users\Administrator\Downloads>PortQry.exe -n 172.17.41.124 -p UDP -e 1434
Querying target system called:
172.17.41.124
Attempting to resolve IP address to a name...
IP address resolved to WIN-AECL8CJVS7E.test.local
querying...
UDP port 1434 (ms-sql-m service): NOT LISTENING
EDIT: I have run NETSTAT and it seems no port in the 14xx range is open at all, although the SQL Server Browser service is running. I must be missing something there...
You did not show your connection string, but I suppose you use your instance name here.
In order to connect to SQL Server the network library has to know 2 things: IP address and a port. Your instance is named and uses non-default port 1438.
So your connection string should use 172.17.41.124,1438 as server name, or, alternatively, you can use instance name like this: 172.17.41.124\EXPRESS2017 but SQL Server Browser should run.
i have an application that needs database(sql server 2008 r2) through public ip, so that the user can use his application anywhere.
i configured the router for port forwading,
i add the port and sql-browser in the firewall.
and when i try datasource = [publicIp]\SQLEXPRESS,1433 i can only access the server when im in the network..
but cannot access the server when im not in the network..and also cant ping the public ip..
i opened port 1433 already.
what seems to be the problem?
Port 1433 isn't enough. When you're running a different than default instance, it will run on a different port. Usually, SQL browser service would help you find it, but you have to forward all the relevant ports as well, which is quite unwieldy. Instead, try setting the correct port manually in SQL server configuration, and connect with the explicit port.
I'm attempting to access a SQL Server which is exposed through an IP NAT mapping. All the ports are open. I don't know the details of the NAT, if it's relevant, since that's somewhere else in the company hidden in a pile of red tape.
Here's what I figured out. When you attempt to access a named instance of SQL Server, the client asks what port the named instance is running on. If I RDP into the SQL Server I can use netstat to find out the port of that instance and can successfully connect through the firewall. However, connecting via the instance name doesn't work. My guess is that the server is responding at some point with it's internal IP address and the client is using that.
Does anyone know if this is true and if there's a way around it?
The instance listening port protocol discovery is subject to the SQL Server Browser Service. This uses UDP on 1434. With a NAT forwarding of UDP 1434 your client should be able to interact with the SQL Server Browser Service (if the SQL Server Browser's UDP response packet can reach back the client, a big if), but even a successful interaction will put your client in a tight spot: now that it knows the SQL Server dynamic listen port, how does it reach it? The NAT would have to dynamically forward the port picked by SQL Server, or it would have to forward all ports.
What I recommend is to have your SQL Server listen on a per-configured, statically assigned, port. See How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port. Have your NAT forward that port. Then in your client use this port explicitly in the connection string. Do not use 1433, the standard port, since I assume that ahead of the NAT is the public internet and 1433 is subject to constant and frequent scans from all sort of bots and vile clusters.
Configure the named instance to run on a static port using SQL Server Configuration Manager. In configuration manager, SQL Server Network Configuration -> Protocols for <named instance> -> TCP/IP -> Properties.
Then supply the hostname and port for the named instance in the connection string. The hostname and port number are specified in the following format (assuming hostname is Test and listen port is 1492):
... Server='Test,1492'; ...
I am trying to use this c socket class, but it only works when I use it on my own computer.
Desktop only
Server is started like this: cSocketServer -p:2030 -i:192.168.178.22
Client connects: cSocketclient -p:2030 -s:192.168.178.22
Works fine.
Desktop server, laptop client
Server: cSocketServer -p:2030 -i:192.168.178.22
Client: cSocketclient -p:2030 -s:192.168.178.22
Exact same as above, but this fires the connect failed: 10060 error. Which essentially means it timed out.
Desktop only (external address)
Server: cSocketServer -p:2030 -i:192.168.178.22
Client: cSocketclient -p:2030 -s:xx.xx.xx.xx
Where xx.xx.xx.xx is my external ip address.
Same error: connect failed: 10060. Port 2030 is definitely open and accessible, because I tested it with a few unrelated applications that allow their users to choose their own ports (like utorrent). While those run, whatismyip.org states port 2030 is open. But when I run my application it sais it Timed-out. Those applications do not have any special privileges in the firewall.
But even if I did mess up some firewall/router settings (which I'm fairly sure I didn't) that wouldn't explain why I can't connect to the server from within my local network. Other services (such as file sharing) work fine so there is definitely a connection between the 2 computers.
Both client and server run on windows 7 64-bit.
Also; for some reason, each client that connects gets their own inbound port assigned or something? Is that normal? When clients connect the server states;
Accepted client: 192.168.178.22:55156
Accepted client: 192.168.178.22:55164
Accepted client: 192.168.178.22:55176
What's that all about?
If two TCP connections have the same source IP, destination IP, source port, and destination port, there would be no way to tell them apart. To ensure they differ somewhere, clients typically assign a unique source port to every outbound connection they make.
As for the errors, you really need to do some troubleshooting. Do the listening sockets show up in a 'netstat'? Do you get the same problem with the firewalls turned off? Are the server and client on the same LAN (for the internal address case)? Is port forwarding enabled and working in the router (for the external address case)?
My bet is that the external address case won't work because you haven't configured the port to be forwarded by your router or your router doesn't support hairpin (local access to external IP). Other programs may work because they support UPnP or don't rely on hairpin (all access to external IPs come from outside your LAN).
I have no immediate explanation for why your desktop-to-laptop won't work inside your LAN. Are you sure both computers are in the same LAN? Can they ping each other?
Get rid of the -i argument to the server, or specify 0.0.0.0 and fix the code so that isn't considered an error, which is itself an error.