I have one question regarding Azure connection from corporate networks.
I have created a VM and a database on azure. I can connect to the DB and RDP to the VM from my home machine. But when I am in office, I cannot connect any of them. This is the error I am getting.
I thought my office proxy is causing the problem, I removed proxy connection but that did not help. I created an instance on AWS and tried connecting to the Azure VM and DB from inside that instance. But that did not help either.
From this, I can think of only one reason that Azure does not allow incoming connection from corporate networks for free tier. I have allowed incoming request from everywhere in the rule of Azure VM and DB.
My azure subscription is free tier.
Can anyone tell me if that is correct or what is the correct way to solve this problem?
UPDATE: The question is not relevant anymore. The problem was with our office network. I have created a NAT to RDP to azure machine and everything is working fine.
I suspect that the Azure firewall is restricting access to your SQL server. As for your VM, you may have some ACLs set up which are restricting access.
To enable the SQL firewall rules:
https://azure.microsoft.com/en-us/documentation/articles/sql-database-configure-firewall-settings/
To check the ACLs on your Virtual Machine endpoints:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/
I was onsite at a client location which disallowed outbound RDP traffic. They set up a SOCKS proxy and installed a SOCKS client on my machine with limited rules to allow RDP to Azure.
Related
We are setting up SQL Always On in Azure VM (IAAS). We followed the steps given in Configure Always On Availability Group in Azure VM manually and the setup is working fine. Since the setup is using the internal load balancer, the listener is available only internally i.e. using a jump box. We are using NSGs to restrict access to the servers from our office IPs and allow access to the SQL Servers from developer machines. This works for direct access to the individual SQL server but not via listener. What can be done to allow access from outside of the VNET?
This subscription is standalone and not connected to the on-premise via site-to-site VPN or Express Route. The resources should be accessed using internet and source IPs are specifically white listed (it is a very small fixed list).
You can configure a Point-to-Site connection to allow your clients to connect the Azure VNet then use sql server.
Yes, the solution to which is to use a Point-to-Site with a VPN gateway deployed.
But, keep in mind that you can have a max of 128 users.
Apart from which, P2S should do the trick here.
I tried to configure a VPN with default values (10.0.1.x) with a point-to-site feature configured.
Azure Websites has been configured too, using the new Azure portal, to point to the Point-to-Site of the VPN.
When a try to contact SQL server of my VM in Azure (Iaas) fails, while locally on the VM I can do it.
I also configured an end point for the port 1433 on the VM with the relative firewall configuration.
Is there a way to check where is the issue using the website ?
Thanks a lot.
Fabio
I have an Azure Cloud Service (Worker Role) that needs to connect to my Azure SQL database and also connect to an external database.
In development the external database was on the public Internet and connectivity was not a problem.
However, the solution now needs to be deployed in a production environment and access to the external database is to be restricted by setting up a Virtual Network.
The Cloud Service, when deployed in the Virtual Network, gets an IP from the subnet, but seems to become inaccessible to the outside world, and is not connecting to the Azure SQL database (I also cannot RDP to it).
This seems to be beyond my level of understanding of networking, but I don't see why it should lose access to its neighbours in the Azure environment.
What am I missing? Do I need to get involved with Endpoints? Is the Virtual Network misconfigured?
Thanks in advance.
Your question is quite vague, in terms that it does describe the whole picture in the best possible way. Let me put my answer based on my understanding about your issue.
First of all - Azure virtual Network is Virtual Network. It is designed to enable secure cross-premisses connectivity with Windows Azure Data Center.
When you deploy a proper PaaS Cloud Service (Worker Role / Web Role) in a Virtual Network, the role instances get IP Addresses allocated from the defined DHCP pool (the VNet Definition).
When you deploy any service in an Azure Virtual Network you have to take care of Name Resolution! Meaning that, if you do not provide a proper DNS Server, your cloud instances will not be able to resolve any address. That includes Azure SQL Database servers. More on Name Resolution can be read here.
Next, but not less important - Azure SQL Database servers are not part of, and, as of March'2013, cannot be added to Azure Virtual Network!
The last statement means that in order for your Worker Role to access Azre SQL Database server, you need to provide a proper DNS server in your Azure Virtual Network.
And lastly, when you deploy a PaaS service into a Virtual Network, in order to access it via Remote Desktop need to:
* Properly enable and configure RDP extension. it will anyway create Input Endpoint. But this is the only way to enable RDP on PaaS right now;
* You could probably enable RDP via PowerShell startup script and access RDP via the VPN tunnel for the Virtual Network - say you configured a Site-to-Site or Point-to-site VPN for your Azure VNet.
Check the building cross-premises Virtual Network guide here.
I've a single Web Role Cloud Service instance running the South East Asia, with a SQL Azure Database running in the same region. I am hitting a firewall issue and the connection is blocked unless I add the Cloud Services public virtual IP to the SQL server firewall.
From everything I've read, if the two systems are in the same region, and 'Allowed Windows Azure Services' is enabled (which adds 0.0.0.0 to the firewall), then the two should be able to communicate internally?
I have some concerns about things being routed inappropriately (is data going outside the network / am I being charged for it), and having to reconfigure the firewall should the VIP change.
Is there some other address I am supposed to access the SQL azure instance by (currently hitting blah.database.windows.net)?
Your understanding is correct. If I were you I would open a support ticket with Microsoft; I have heard of this issue before, although I never experienced it myself. This sounds like an issue, so report it and watch your next invoice carefully.
Firstly,
Allowed Windows Azure Services - Will allow only azure services to access the database.
Secondly,
To be able to access the database server from any other endpoint, you need to add firewall rules to allow those specific IP ranges. If you want to connect from a machine with ip, 132.99.xx.xx you need to add a rule with start IP and end IP as 132.99.xx.xx
Hope this helps!
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.