I am new to Apache Ignite. I have an application for which I am trying to utilize Apache Ignite for a distributed cache.
I currently have 3 servers to process to serve the incoming requests and if one server is down, one of the other two servers would need to handle the request.
I have configured the "REPLICATED Cache" in the Cache Configuration and have configured the IP Address for the servers in use using "TcpDiscoveryVmIpFinder".
The topology snapshot always shows me one client and one server when all three servers are up, and killing one server disconnects the client node even if the other two servers are still up.
I am having the same issue when using multicast node discovery. One server is identified and the other two servers do not join the topology even though they have the same multicast group configuration.
First off, I already know that Windows Firewall is blocking my connection -- I just don't know what to do about it. When I turn WF all the way off, my remote connection works. I already have a Rule to allow incoming requests at port 1433, and it seems that's the right port, but I'm unsure. Now for more details.
I had SQL Server 2008 R2 on my remote dedicated server and had no problem connecting remotely via SSMS. But then I installed SQL Server 2012. It works fine, but I was forced to create a named instance for it during installation because the default instance is in use by SQL08.
My ASP.NET connection string running on that box works fine and connects to sql12 with no problem. Here is the obfuscated connection string:
Server=myserver\MSSQLSSERVER2012;Database=MyDB;User Id=Me; password=MyPaSS;
It looks like the named instance is using port 1433. I verified that SQL Browser is active and running. I have a windows firewall exception that allows sql server and port 1433, though that was there before and I'm wondering if that's only working for the now-disabled SQL08 (how do I ensure this is working for SQL12).
Say the IP to that server is 1.2.3.4
From SSMS I have tried connecting to the server thusly:
1.2.3.4
1.2.3.4\MSSQLSSERVER2012
1.2.3.4\MSSQLSSERVER2012,1433
Nothing works. Always the error is:
I have read a number of articles on this topic and they all say:
enable SQL Browser (done)
open a port in Windows firewall (seems done ??)
So how can I discover what exactly I need to do in Windows Firewall to fix this? I cannot turn the whole thing off, this is a public web server.
Here is the list of the ports that SQL Server Features use. Depending on the features/services you use you may need additional ports TCP/UDP opened. Also under server properties > connections > confirm that Allow remote connections to this server is checked. The instructions of remote connection is for 2008, since you mentioned that turning firewall off that you are able to connect remotely then I would guess this is not needed but would not hurt to double check this.
Configure the Windows Firewall to Allow SQL Server Access
Enable Remote Connections
A short answer is:
SQL Server default instance uses TCP port 1433, unless messed about with (don't do it!). If you only have a default instance, that's the only port you need, I believe - SQL Server clients don't use the browser service to find a default instance.
SQL Browser comes into play if named instances are used. This listens on UDP port 1434; it responds to requests for port numbers for named instances.
By default, named instances use dynamic TCP ports - so a different port each time they start up. The browser sorts this out for you but it's a pain through a firewall.
There is no reason why you shouldn't set a fixed port in SQL Server config manager for a named instance (say, TCP Port 1434 or whatever) so that you only need to open one extra port for the named instance.
If you use named instances, adding port 1433 is not enough.
You can reproduce this:
install a named instance
add inbound rule 1433
allow remote connections
When you try to connect you get an error that the server cannot be found. When you turn of the firewall it all works, so there must be another port needed to get it to work.
You need to open port 1434 UDP and start SQL Browser, now it works.
One or more of the following solved the problem and enabled me to connect with my remote sql server:
Allow remote connections in mssql properties
Enable MSSQL exe in winfirewall
Enable SQL Browser in winfirewall
Explicitly opened port 1433 tcp and 1434 udp
SQL Browser running as a service
This worked for me :)
If you have tried all of the above and you're still getting that error - try adding the IP and instance name to the host file of the server you are connecting FROM like this:
111.11.111.1111 INSTANCENAME #IP and Instance Name of server connecting TO
This worked for me after DAYS of going through opening ports, UDP, TCP/IP, etc. I was able to connect using a connection string with the IP, but never the instance name itself. Confirmed the login info was correct, SQL Browser was enabled and running. I hope this helps.
I am confused about ports.
I find it odd that we need to bind different servers to different ports.
Example:
Apache binded on 8080, Express.js can't bind on 8080
How does server port binding differ from application port listening?
Example:
Different browsers, ie, chrome, firefox, can listening and communicated on port 80?
This issue came up when trying to run "grunt test:unit". There was a tomcat server that was already bound to 8080, but the server grunt starts, middleware I believe, is able to startup, but it is not able to to capture the browser. Stopping the tomcat server made things work.
Actually, Firefox, Chrome, etc. use different source ports. They don't listen on ports; they connect to remote servers. The servers are listening on one port (80). The source port from which the browser connects is chosen randomly and is a high number. You can check this using netstat. Their destination port is the same (80).
The reason why you can't have multiple servers binding to the same port* is because the operating system wouldn't know which application to hand off an incoming connection to.
*actually, you can, but it's complicated. SO_REUSEPORT
The reason only one application can control/listen on a port at one time is this:
When the OS receives a request for, say, port 80, and there were two apps listening on it, how is it supposed to know which app to pass on the request to?
The reason multiple apps can access the web at once is because they don't do it the same way - they use an unused port (maybe something like 62332 or whatever) and only the destination is port 80, for example.
That's what ports are for - so that you can run more than one server at once per machine.
Not sure if i'm really up-to-date, but i'm looking in a way to convert my existing project to use HTML5 websockets.
Here's my situation :
- Client runs a modified java vnc applet with extra parameter (CONNECT).
- Modified stunnel listenin on webserver (with both public, private IP) port 443
- Client connects to 443 and sends (prior to RFB) a HTTP packet like :
'CONNECT 10.0.0.1:4001'
- Stunnel opens a new stream to 10.0.0.1:4001 using SSL wrapper
- VNC Server (#10.0.0.1:4001) responds, connection is established.
Now I want to get rid of the Java Applet and switch to Websocket using NoVNC.
I want to be able to :
- Open a single port on the webserver (HTTPS preferably)
- Have client connect using HTML5 only (no more java applet)
I cannot change :
- VNCServer will still be listening on private LAN only.
- VNCServer will still listen to a bunch of ports, each corresponding to
a virtual server
Questions are :
- How to give NoVNC the notion of target HOST:PORT ?
- Is stunnel still be usable ? Or should I change to websocket proxy ?
If anyone has a starting point, i'd really appreciate !
Disclaimer: I created noVNC so my answer may be heavily biased ;-)
I'll answer you second question first:
stunnel cannot be used directly by noVNC. The issue is that the WebSockets protocol has an HTTP-like initial handshake and the messages are framed. In addition, until binary payload support is added to WebSockets, the payload is base64 encoded by the websockets proxy (websockify). Adding the necessary support to stunnel would be non-trivial but certainly doable. In fact noVNC issue #37 is an aspirational feature to add this support to stunnel.
First question:
noVNC already has a concept of HOST:PORT via the RFB.connect(host, port, password) method. The file vnc_auto.html at the top level shows how to get noVNC to automatically connect on page load based on the host, port and password specified as URL query string parameters.
However, I think what you are really asking is how do you get noVNC to connect to alternate VNC server ports on the backend. This problem is not directly addressed by noVNC and websockify. There are several ways to solve this and it usually involves an out-of-band setup/authorization mechanism so that the proxy can't be used to launch attacks by arbitrary hosts. For example, at my company we have a web based management framework that integrates noVNC and when the user wants to connect to the console, an authenticated AJAX call is used to configure the proxy for that particular user and the system they want to connect to. Our web management interface is internal only.
Ganeti Web Manager uses a similar model and the source is available. They have a fork of VNCAuthProxy that has WebSockets support. They use a control channel from the web interface to the VNCAuthProxy to setup a temporary password associated with a specific VNC server host:port.
Also OpenStack (Nova) integrates noVNC uses a similar out-of-band token based model to allow access with their nova-vncproxy.
Some links:
Ganeti Web Manager
Wiki page about how noVNC works in Ganeti Web Manager
Ganeti Web Manager sources
Ganeti Web Manager VNCAUthProxy sources
Using noVNC in Nova/OpenStack
OpenStack fork of noVNC
Old nova-vnc-proxy code
Current nova vnc proxy code
I have connected for the first time to an existing network over VPN. I can ping the IP address which is used by the SQL Server from the VPN client, but SSMS does not connect to the SQL Server. I am using the right login id and password.
Why could this happen? Any ideas?
On a default instance, SQL Server listens on TCP/1433 by default. This can be changed. On a named instance, unless configured differently, SQL Server listens on a dynamic TCP port. What that means is should SQL Server discover that the port is in use, it will pick another TCP port. How clients usually find the right port in the case of a named instance is by talking to the SQL Server Listener Service/SQL Browser. That listens on UDP/1434 and cannot be changed. If you have a named instance, you can configure a static port and if you have a need to use Kerberos authentication/delegation, you should.
What you'll need to determine is what port your SQL Server is listening on. Then you'll need to get with your networking/security folks to determine if they allow communication to that port via VPN. If they are, as indicated, check your firewall settings. Some systems have multiple firewalls (my laptop is an example). If so, you'll need to check all the firewalls on your system.
If all of those are correct, verify the server doesn't have an IPSEC policy that restricts access to the SQL Server port via IP address. That also could result in you being blocked.
When this happens to me, it is because DNS is not working properly. Try using the IP address instead of the server name in the SQL Server login.
Make sure SQL Server is enabled for TCP/IP (someone may have disabled it)?
This will also help you to check/verify the port number the SQL instance is using (in case someone changed it from the default of port 1433).
Obviously port 1433 (or whatever port SQL is listening on) needs to be unblocked by any firewalls between your machine and the box SQL is running on.
To check SQL's network configuration (requires SQL Server Client Tools installed):
Start -> Programs -> SQL Server 200x -> Configuration Tools -> SQL Server Configuration Manager
Connect to the machine you need then expand the Tree Item (LHS) "SQL Server Network Configuration", then pick instance. You should have four options - Shared Memory, Named Pipes, TCP/IP and VIA. You can check that TCP/IP is enabled in the RHS window.
If you double click TCP/IP and hit the "Advanced" tab, you can also view the Port number.
Other thoughts.. Are you using SQL Authentication or Windows (Domain) authentication?
If SQL Authentication (which I assume you are using given you said username and password), are you sure the SQL instance you're connecting to has mixed mode authentication enabled? If not, you have to connect as Administrator and change the default security settings to allow SQL authentication.
If Windows Authentication, could your network be using Kerberos potentially? One would think the VPN credentials would be used for the handshake. I'd check your account has appropriate login rights.
I also had this problem when trying to connect remotely via the Hamachi VPN. I had tried everything available on the internet (including this post) and it still did not work. Note that everything worked fine when the same database was installed on a machine on my local network. Finally I was able to achieve success using the following fix: on the remote machine, enable the IP address on the TCP/IP protocol, like so:
On the remote machine, start SQL Server Configuration Manager, expand SQL Server Network Configuration, select "Protocols for SQLEXPRESS" (or "MSSQLSERVER"), right-click on TCP/IP, on the resulting dialog box go to the IP Addresses tab, and make sure the "IP1" element is Active=Yes and Enabled=Yes. Make note of the IP address (for me it wasn't necessary to modify these). Then stop and start the SQL Server Services. After that, ensure that the firewall on the remote machine is either disabled, or an exception is allowed for port 1433 that includes both the local subnet and the subnet for the address noted in the previous dialog box. On your local machine you should be able to connect by setting the server name to 192.168.1.22\SQLEXPRESS (or [ip address of remote machine]\[SQL server instance name]).
Hope that helps.
Check that the port that SQL Server is using is not being blocked by either your firewall or the VPN.
I have this issue a lot with Citrix Access Gateway. I usually get a timeout error. If you are able to connect to the database from a client on the network, but not from a remote client via VPN, you can forget most suggestions given here, because they all address server-side issues.
I am able to connect when I increase the timeout from the default (15 seconds) to 60 seconds, and for good measure, force the protocol to TCP/IP. These things can be done on the Options screen of the login dialog:
As long as you have the firewall set to allow the port that your SQL Server instance is using, all you need to do is change Data Source from =Server name to =IP,Port
ie, in the connection string use something like this.
Data Source=190.190.1.100,1433;
You should not have to change anything on the client side.
You may not have the UDP port open/VPN-forwarded, it's port number 1433.
Despite client protocol name of "TCP/IP", mssql uses UDP for bitbanging.
SQL Server uses the TCP port 1433. This is probably blocked either by the VPN tunnel or by a firewall on the server.
When connecting to VPN every message goes through VPN server and it could not be forwarding your messages to that port SQL server is working on.
Try
disable VPN settings->Properties->TCP/IP properties->Advanced->Use default gateway on remote network.
This way you will first try to connect local IP of SQL server and only then use VPN server to forward you
I was having this issue too with SQL Server 2017.
I'm on the same network as the server via VPN and can ping it. After being frustrated that no authentication method would work - I set up an SSH server on the SQL server - and I was able to connect normally. This confirmed the correct port wasn't being hit for some reason. I even created a new user accounts, domain accounts, firewall checks on both ends, etc...
The solution for me was:
1. Set Connection to strictly use TCP/IP on SSMS
2. Use a custom string to point to the default port (ex: Data Source=192.168.168.166,1433;)
All the other comments above haven't worked so far. It looks like it was mandatory to include the port (even though its default).
This is what fixed my connection problem of accessing the SQL Server 2012 Database via VPN
With the SQL Server 2012 Configuration Manager,
I went to the SQL Server Network configuration
Then clicked on the NEW server instance and double-clicked the TCP/IP protocol
[I had also previously enabled this option and rebooted the server but that did still not fix it]
now that the TCP/IP was enabled, I noted that all of the IP port slots in the 'IP Addresses' tab of the TCP/IP Properties advanced dialog were set to Enabled=No.
I was curious to why my new installation set all of these IP slots to NO rather than Yes, so I just changed them to YES.
Now the connection to the sever via VPN works great, I did not change any port numbers.
Note: I also had SQL Server 2008 default from the Visual studio 2010 uninstalled, but I do not think that had a direct effect to the TCP/IP situation. A coworker told me that the 2008 and 2005 installations which come with visual studio may interfere with SQL 2012.
If you're using sql server 2005, start sql server browser service first.
Try changing Server name with its IP
for example
SERVERNAME//SQLSERVER -> 192.168.0.2//SQLSERVER
its work flawlessly with me using VPN
Make sure to add port 1433 to firewall exceptions and make sure "Any IP Address" is checked under Firewall port setting(see attachment).
In case everything works fine on your LAN, but fails when client application tries to establish connection thru a VPN, you might consider changing your router MTU (Maximum Transmit Unit) settings from AUTO to a lower than maximum value.
Further references:
https://faq.draytek.com.au/2021/03/15/adjusting-vpn-mss-mtu-settings/
https://community.spiceworks.com/topic/217130-mtu-issues-in-vpn-connections
https://community.ui.com/questions/EdgeRouter-4-FortiGate-VPN-Performance-issues/84932edc-d2ee-4bdd-bd47-e0993210f17e?page=1
My solution was enable and start the service "SQL Server Browser".
Be also sure, you allow this service in your firewall.
I have a similar problem but with a strange effect.
If I use SMSS over a VPN (site2site) I can't connect. But If I use OpenVPN client it's working.
And this isn't the only thing... Using the same site2site vpn but with DBeaver or HeidiSQL I can connect... I wrote a simple c# console app to test the connection and it's working. The only issue is with SMSS.
I don't know why but I'm very curious about that :)