So I'm building a pretty simple application in Access 2013, and our company recommended using Azure SQL Database for the backend (due to the cost and simplicity of setting up/maintenance). However, their recommendation left us with a massive problem. Port 1433 is blocked on our company's network, and it's such a big company, I can't get it unblocked.
I don't know too much about having a middle-tier, but what are my options here? Is there a simple way to connect to the database without accessing this port?
Thanks
You could fire up a Azure VM with SQL Server already installed. Then you should be able to change the ports to your liking.
Check out this post...
http://roberteichenseer.wordpress.com/2012/07/06/nderung-default-port-sql-server-innerhalb-einer-azure-vm/
You only need to open up 1433 outbound in your works firewall not the 1433 inbound.
Most security teams are ok to open the outbound port. Opening the outbound will give you the access to connect and access the data inside Azure.
I have a server running on my machine. I want to send a request to the server using different IP address to test a web application. I only have the machine on which the server is installed. I have been testing as a single user but now I would like to let the server think that the request is coming from a different ip address even though it is from the same machine. How can I do that?
Here are the 2 solutions that might be possible in your situation
1- To change the ip address :
Pick an ip from the free proxies here: http://www.freeproxylists.net/
And enter the info in firefox just like this page says:
http://www.wikihow.com/Enter-Proxy-Settings-in-Firefox
Note: You may pick a proxy with port 80.
Then you are good to go...
2- Or you might use a Virtual Machine installed on the same computer as the server and access the website right from it but beware not to use bridged connection.
I have successfully executed my SQL script on Microsoft SQL Server 2008 R2. Since I am a novice at this software, I would like to know how do I connect this database with my android application? Any help would be appreciated. Previously, I was making use of MySQL on XAMPP and hosting the database using my local machine. I made use of services being provided by http://www.noip.com to host the database since I do not have a static ip address.
Thanks in advance.
Your client will have a connection string. It will usually look like one of the examples here:
http://www.connectionstrings.com/sql-server-2008
You'll probably use the "IP Address" example. From the link above:
Connect via an IP address
Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;Initial Catalog=myDataBase;
User ID=myUsername;Password=myPassword;
You're trying to use http://www.noip.com to deal with the fact you don't have a static IP address on your home network.
I would table this part of the problem for the time being. Go to your router and find your "external IP address"
You'll have to setup some port forwarding on your local network. I'm assuming (since you didn't give any detail) that you have a cable-modem at home and a wireless router. Your router will have to be configured to handle port forwarding so that when a request comes into 55.555.555.55 (your "external ip").......it will be forwarded to your internal Sql server (like 192.168.1.33). And you'll have to know the port. "1433" is the normal port, but can be changed.
So again, any requests coming into your cable-modem and router to "55.555.555.55:1433" will have to be forwarded to your internal IP and port "192.168.1.33:1433".
Your local sql server may have firewall rules that you need to alter to open up "192.168.1.33:1433" to your router.
If you get all that working, you'll have to wire up http://www.noip.com, which I am assuming gives you a static IP address and will link up your "55.555.555.55" to something permanent, with the caveat that when your "55.555.555.55" changes to "55.555.333.44", it'll handle the mapping for you.
So if noip gives you an IP of "777.77.77.7777" (which maps to "55.555.555.55" or "55.555.333.44" or whatever IP your internet provider gives you), you'll change your connection string to be "777.77.77.7777"
That's alot of drama.
But if you want to tackle it, there are some helper hints.
At the end of the day, your client app will have a connection string with an IP address and a Port Number in it, and that client will have to be able to reach your sql server.....through all the voodoo channels.
Good luck.
I would get this working first:
Data Source=55.555.555.55,1433;Network Library=DBMSSOCN;Initial Catalog=myDataBase;
User ID=myUsername;Password=myPassword;
And then work in the noip.com part later. So eventually your connection string will become:
Data Source=777.77.77.7777,1433;Network Library=DBMSSOCN;Initial Catalog=myDataBase;
User ID=myUsername;Password=myPassword;
I created an AMP web application that was originally going to be served from a traditional 3rd party host.
As we finished up, the client decided to host it internally, on a server in their office network. The application is only meant to be available to staff members, but those staff members will often be off-site. I had no involvement in setting up their network, which uses at least one server running windows server 2003. The client machines I saw were XP.
I set up Apache, MySQL and PHP on the server 2003 machine, and installed the application. The application is built on the CodeIgniter framework, so I set the base_url to the internal IP (192.168...), and we tested from within the network. Everything worked fine.
Next, we asked their network guy to open port 80 for apache. I set the base_url to the external IP, and tested from my home (using the external IP as the web address), and it works fine.
However, when attempting to access the application using the external IP from within the network, they're unable to connect. I can reset the base_url to the network IP, and they can access it using the network IP, but then it the application fails when connecting externally (since the base_url, used throughout the application, is pointing to the internal IP).
It suppose I could let CodeIgniter determine the base_url (by leaving the variable as an empty string), but would rather figure out why the external IP fails in-network, and try to correct that.
The server we're using is not dedicated to the AMP stack (in fact, it has at least one other application broadcasting to the internet that must have been using IIS, as well as an FTP server used for office scanners), so I suppose there might be some conflicts there.
I know very little about windows networking. A quick search suggested this might be because of NAT, but didn't offer a work-around.
Their network guy has no suggestions, and said that everything should be fine.
Is it possible to have users inside the network access the Apache server using the external IP, and if so, what needs to happen to enable that?
TYIA
Your client's NAT router is configured to forward packets arriving on its external interface for its external IP with port 80 to the internal machine, port 80, after re-writing the source and destination IP addresses in the packets.
From within the network, attempts to connect to the external IP address will be routed to the default route on the machines, the router's internal interface. This interface is not configured to forward packets back into the network.
Configure the application to listen on all IP addresses. Make sure that the server knows that the clients know it under several hostnames -- the internal IP address and the external IP address.
You might be able to re-write the NAT firewall rules on the router to perform the port forwarding for the internal interface as well, but off-the-shell equipment common in homes and small businesses do not make this task easy. More expensive gear (or home-built *BSD/Linux router machines) can do this without much effort, but it would needlessly add traffic to the router.
This isn't Apache related, nor is it CI related. It's often impossible to reach the external IP address from within the network.
Frankly, I don't know exactly why that is. I do know that it's related to how NAT (Network Address Translation) works or at least how it's implemented.
For a detailed overview of why this is, you should ask this question on serverfault. If you're simply a programmer who has to deal with it, accept that NAT usually works only from inside to outside and outside to inside, but not inside to inside.
You already mentioned one of the solutions in your question - don't use base_url. You could also simply run the server on an external IP address (not your company IP, but let's say a datacenter or something).
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 :)