I have 3 VMs in Azure, one of them is DC and DNS, the other one is going to be SCCM, the ther one is SQL server.
I joined the two VMs to my DC. They have correct IP config. One of them is just fine. I can ping DC from the SSCM and vice versa.
But from the SQL server I cannot ping. nslookup does not work correctly either, but the IP config is correct.
Does any one know where is the problem?
Note: DNS server is fine. Also, I have records in DNS server that are pointing to SCCM and SQL.
Ping is disabled by default on the Windows Server VM's. Sign-in to the VM you want to ping and open the Server Manager (icon in the lower left corner).
In the upper right corner where the menu is, select Tools -> Windows Firewall with Advanced Security. Click on the Inbound Rules in the left navigation, locate the File and Printer Sharing (Echo Request - ICMPv4-In) rule. Right-click on it to enable it.
Now you should be able to ping it from other VM's in your Virtual Network.
Related
i get this error for installation script that worked perfect on EC2 vm but now seems that i can't reach the site , should i add some inbound rule or something to enable apache2 server ? the error in the chrome is
This site can’t be reached *.*.*.*.com’s server IP address could not be found.
Try running Windows Network Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN
Network Security Group
Azure VMs do not have any ports open firewall ports by default unless you open them when you provision your VM. When you created your Azure VM in the Azure Portal, you likely created a Network Security Group for the VM. If you didn't specify any ports to open during the VM's creation, you'll need to open up the VM's firewall.
To Open Ports
To open up the ports on the firewall, head out to the Azure Portal (where you set up the VM). Find the VM in the list of resources. It should take you to a page for your VM where the name, status, location, size, IP address, etc will be displayed. On the left side, you'll have a vertical menu > Select Networking. From there, you'll be able to see currently active firewall rules for the VM. Since you're likely missing HTTP (80) and HTTPS, select add inbound port rule. From the dropdown for service, select HTTP and assign a name/priority. Perform the same options, except this time selecting HTTPS (443). Press save and test. You should be able to access Apache running on the VM.
Additional Troubleshooting
The script you used may have inadvertently set up the VM's iptables. You can view Linux's firewall with sudo iptables -L to verify that no firewall rules have been enabled. Since Azure handles the firewall, you shouldn't need any iptables rules, but they could always be added for additional security.
This answer assumes that you do not have Azure's Load Balancing servers installed in front of the VM.
Currently, I am using SQL server 2012 and running in window 7 64 bit.
My question is
How can I connect this server from another computer (window 10 64
bit)?
What have I done?
My server name is NB-1608-001\SQLEXPRESS2 and I already enable TCP/IP status and Name Pipes status and Shared Memory status
I already set TCP port 1433 for IP4 and IPAll.
I already enable "Allow remote connection to this server" for this server
I already enable "SQL Server and Windows Authentication mode"
The two computer are on the same network
I created UDL file in window 10 computer (I set server name to :"\NB-1608-001\SQLEXPRESS2")and try to connect to sql server but this say:
Test connection failed because of an error in initializing provider :
Unspecified error
After searching some solution on google,
I created InBound and Outbound rule for IP 1433 in Window 7 Computer
But it's still not working.
I tried another way for make sure whether this two computer is connected or not.
I typed "\NB-1608-001" in network and this said
Windows cannot access \NB-1608-001
After Diagnose,It said
file and print sharing resource (NB-1608-001) is online but isnt
responding to connection attempts.
So I assume the two computers are connected.
Is there still another solution?
My main reason is to run the c# app and connect to another computer's SQL server.
Thanks
(some notes: 1433 is a TCP port not an IP, you have to put two backslash \\ for UNC path but maybe this is a StackOverflow escape problem)
I suggest to disable the firewall just for testing purpose to all firewall profiles (maybe you set inbound rule only for private profile and your network is flagged as public).
I would try a ping to the machine name to be sure that its name is resolved by the client.
I would check in the Sql server Configuration manager that TCP client protocols is enabled for both SQL Native clients (32 and 64bit) and TCP/IP under Protocols Network Configuration.
You did not say what is your client, I would try to connect with SQL Server Management Studio, just to be sure this is not a problem related to your client.
This reading can be useful:
https://blogs.msdn.microsoft.com/sqlexpress/2005/05/05/how-to-configure-express-to-accept-remote-connections/
We have a Win Server 2008 box being hosted (dedicated) for us.
I need to connect to one of it's DB's from a server in our LAN.
What started out as a "sure, I'll just throw that together for you real quick" project has turned into a week-long hair-pulling pile of WTF :)
I am able to RDP into that server without fail or issue.
When I tried to connect to the DB, I got a generic "could not connect" error, so I went hunting.
Telnet attemtps and pings time out.
Since then, we have tried endless variations of firewall settings (including wide open), and still ... no go.
In addition to our firewall, the hosting provider also has a firewall layer.
We turned on all logging, and we don't even see any connection attempts at our FW.
We then had the hosting provider turn on all logging, and they don't see any connection attempts either!
Hrmmmph
I'm at a complete loss.
Any suggestions?
BTW, while I'm comfortable enough with all this to explore and make changes, my experience with firewalls and stuff is fairly limited, so don't hesitate to dumb it down ;)
It is hard to give just one answer to this question, because the interim results of the problem analysis lead to different steps that you need to do next. It will more likely be a step by step help with tracing down the problem.
Do not trust any firewall setting (esp. not any that someone else did, and again esp. not if you don't know him), unless you tested it. Firewall settings are tricky and even experienced professionals get them wrong now and then.
In the guide below, I will write <win2008server> in commands where you have to put the name or IP of the windows 2008 server to which you want to connect. On the other side, I will use the expression "office PC" when I mean your workstation PC in the office from where you are trying to connect to the win2008server.
STEP 1: Checking the Endpoints
1.) Can you telnet to the RDP port?
On your office PC, try this on a command prompt:
telnet <win2008server> 3389
This is to make sure that DNS name resulution works for telnet, as well as network hardware and routing. It should, because you can use RDP to establish this connection. However, anything can get in between, like the telnet command being in any way configured nonstandard or being replaced for whatever reason on a company pc (sysadmins have strange ideas at times...).
2.) Can you telnet locally on the win2008server to the database?
When logged in using RDP on the win2008server, open a command prompt on the server and issue the command
telnet <win2008server> <database port>
That means you are trying to connect from the server to itself. This is to make sure the database port is open on the server.
STEP 2: Checking the Firewalls of the Endpoints
If for 1.) and 2.), your answer is yes it works, you have to test if either the remote side can not be reached or your location can not connect to the internet on the port you are testing (database port). You do this by replacing the respective other side with any other host on the internet for which you know it's reachable or can reach other servers. Typically, you google for a port checker ;)
3.) Check if the win2008server can be reached from another location than yours:
3.1.) Check if the RDP port of the win2008server can be reached from a third party location:
Google for port checker and take the first result (e.g. http://www.yougetsignal.com/tools/open-ports/ ). Type in the name or IP address of the win2008server and the RDP port, usually 3389 . Click on "check" and wait for the success or the timeout.
3.2.) Check if the database port of the win2008server can be reached from a third party location:
Do the same as in 3.1.), just with the database port instead of the RDP port.
4.) Check if you can connect to an outside server on the database port:
For this to work, you need to know a server or create one, which is somewhere outside on the internet, and which listens on the database port. You typically do this by keeping your private PC at home run and accessible through RDP or SSH, and there you open a server and configure your private internet router to forward the connection correctly.
Another way to do this test is webspace with SSH access. Many webspace providers nowadays allow for an SSH login (usually any webspace at $4/month and above).
Let's assume you have SSH access to any such third party place. You can use nc (netcat) there to open a server socket on the database port with this command:
nc -l <database port>
If it's your private PC at home, you usually have to also configure your private router and set up a dynamic DNS name for your internet access for the whole story to work out. You do not have this extra work with a webspace based SSH login. However, there you can not test ports below 1024 because you do not have the privileges. Good luck with this ;)
After you got this, try connecting to the port that you opened:
4.1.) From your office PC with
telnet <third party location> <database port>
4.2.) If 4.1.) does not work, also try with the port checker, because you might have gotten something wrong with setting up the server. Look at 3.) for this, and use the <third party location> and <database port> with the port checker (fourth party check).
STEP 3: Blaming ;)
At least one of the things should have failed by now and you can start calling people and letting them know about your tests and the results. You should be able to combine the results logically, but never start with that. Think about how to convey the information. Start out with your findings and then let them have a moment for their own conclusion. It can be difficult to tell someone in another company or department that their firewall isn't configured correctly. They might deny this even in the presence of proof. Be patient. Explain your findings again. Hint at the conclusion. This can be the trickiest part of the whole problem solution.
I have to say that today I had the same problem.
My solution was just to edit secpol.msc and disable all the FW profiles; then, run services.msc and also disable Windows Firewall service.
After this server was pingable for me.
I set up an SQL server on my Windows 7 PC.
I have a laptop, from which I want to connect to the SQL server (using visual studio 2010).
I need to fill in a "server name" when creating a database connection.
I tried "My.IP.Address/SQLEXPRESS,custom-port", but that doesn't work. All examples talk about using server names which are formatted like so "TOM-PC/SQLEXPRESS", but I have an important requirement:
I want to be able to connect from anywhere (not only when in the same local network), therefore I'm trying to use the IP address (the port isn't simply 1433 since my ISP blocks it).
The custom port is open, and reachable in tests.
I've been Googling this all day long, but can't find a solution. Please help!
Thank you,
Tom
To access from a remote location, you need to setup port forwarding on your router. If you have a static external facing IP address, then you can use that for your server address (123.123.123.123\SQLEXPRESS), otherwise you will need to setup a dynamic DNS service like DynDNS.com that will give your router a hostname.
DynDNS Free allows you to create a
hostname that points to your home or
office IP address, providing an
easy-to-remember URL for quick access.
We also provide an update mechanism
which makes the hostname work with
your dynamic IP address. We continue
to offer this service free to the
Internet community as we have done so
for nearly 10 years.
should it not be My.IP.Address:custom-port/SQLEXPRESS ?
If you are saying that you have a PC at location A that has SQL and you want to be able to access it from anywhere, well, then you're going to need a static IP from your ISP, a firewall with the proper NAT rules. And even then, it'll be a different IP when you're local (within the same network) than it is when you are at the local coffee shop.
My suggestion would be to use the local server reference and install SQL on your laptop. If you publish your work to your PC at home, then it'll use the local SQL server there too. This is what I do. I use RedGate tools to sync up my DBs.
If you have SQL and VS on the same machine (your laptop) and are trying to connect to the SQL server from VS (e.g. in debugger), then try the following: (I'm working like this all the time)
You can use (local) or . as the server in a SQL connection to refer to the local machine.
In your case:
(local)\SQLEXPRESS
or
.\SQLEXPRESS
Is it possible you overlooked turning on TCP/IP fro SQLExpress in the configuration manager?
Have you tried using a wild card? For example let others access you through '%', since you want your computer to be accessed anywhere, your MySQL host is actually your IP address.
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 :)