I have created successfully a Hybrid Connection (ServerA) and linked it to my Azure Web App. The status is successfully connected: ServerB:1010 is defined
On My On Premise machine (ServerA) I can connect to a HTTP Service which is running on ServerB:1010 but I can't install the Hybrid Connection Manager on ServerB because of other restrictions.
If I Use WebClient.UploadData('ServerB:1010', data[]) in my Azure Web App I receive following error.
Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions.
If I connect to a database server MySql or Oracle which are also accessible from this server I don't have any problems
I have created successfully a Hybrid Connection (ServerA) and linked it to my Azure Web App.
Remove it and add a Hybrid Connection to Server B instead. Install the Hybrid Connection Manager on Server A. The HCM will act as a reverse proxy.
Hybrid Connections do not care which server has the HCM installation as long as that server can reach the DNS name you specify in the New > Hybrid Connection Portal blade.
Example traffic flow for WebClient.UploadData('ServerB:1010', data[]):
Web App ---> Hybrid Connection ---> HCM on Server A ---> 1010/TCP on Server B.
<--- <--- <---
There's an easier way to test. Open the Kudu console and do
tcpping ServerB:1010
CORRECTION: The tcpping test is very misleading since you're handshaking the Azure-end of the Hybrid Connection, not the on-prem application's TCP endpoint. And that may happily reply to you even though the on-prem stuff is not connected. Here's what i mean:
Always test at application layer (e.g. with curl.exe http://webservice.corp.local from the Kudu Console)
You must use names instead of IP addresses. Use the full FQDN to reference ServerA and ServerB both in the Portal setup and in your code. Hybrid Connections work by intercepting DNS calls at OS level and resolving them to the magic 127.0.0.x which is then routed over the Hybrid Connection to on-prem.
TL;DR version:
Instead of
10.10.10.2:1010
use
ServerB.domain.local:1010
both in the Portal setup and when referencing the on-prem host in your code.
Here's what happens if you use an IP Address instead of name:
In Kudu's DebugConsole:
D:\home>nameresolver 192.168.0.4
Server: Default
Non-authoritative answer:
Name: 192.168.0.4
Addresses: 127.0.0.3
D:\home>tcpping 192.168.0.4:80
Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 192.168.0.4:80
Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 192.168.0.4:80
Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 192.168.0.4:80
Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 192.168.0.4:80
Complete: 0/4 successfull attempts (0%). Average success time: 0ms
D:\home>curl -s 192.168.0.4
This is iisstart.htm from IIS 8.5 on Windows Server 2012 R2, on-prem.
So depending on what APIs you call (APIs that take 192.168.0.4 as FQDN vs IP Address) it kinda works.
You can't use tcpping with Hybrid Connections. It doesn't really tell you anything. All that tells you is that you hit the local socket that will catch your TCP traffic headed to your HC endpoint. It doesn't actually go through the connection.
As far as using an IPv4 address with Hybrid Connections, it can work and yet sometimes it won't. The reason for that is that the feature functions by catching the DNS request. If you are using a client library in your application code that doesn't do a DNS lookup on IP addresses then it won't go over the Hybrid Connection.
The DNS name must resolve to the correct IP address from the host(s) where you have the Hybrid Connection Manager running.
Going to the original question, you need a Hybrid Connection defined for your endpoint of ServerB port 1010. The DNS name used for ServerB must resolve from the host(s) running the HCM. Your HCM needs network access to ServerB port 1010 and to Azure. Your status says Connected which means that your web app can talk to your Hybrid Connection Manager for that endpoint. So, test connectivity from the host running the HCM to your desired host:port endpoint. Use a DNS name if you can. I hope this unblocks you.
Related
We develop an application that fetches data from our client's databases by means of Azure Hybrid Connection.
The problem is that when client whitelists just Azure Relay address on their firewall - connection is becoming unstable, it may work one second and fail the other one (with the following error: "The specified network name is no longer available.". When they open web ports for any addresses - everything works fine.
I suspect HCM is doing calls not only to the configured Azure Relay, but maybe to some other Microsoft addresses.
When configuring firewall rules on HCM side, what addresses (besides Azure Relay address) the client should whitelist?
I have a simple Asp.Net Core Azure Web App that needs to make a http get request to an on-premise Rest service. This Rest service is hosted on IIS with bindings set only for port 443. I've setup a new Hybrid Connection in Azure and added it to the Web App. At the on-prem side, I've installed Hybrid Connection Manager and entered the connection string for the Hybrid Connection - this now shows as "Connected".
Problem is, when executing the line of code that makes the get request, the following error is thrown:
System.AggregateException: One or more errors occurred. (No such host is known) ---> System.Net.Http.HttpRequestException: No such host is known ---> System.Net.
There's an interesting blog post here: Microsoft Blog which states that the connections should be setup without using the fully qualified domain name (FQDN) - server name suffixed with organisation.co.uk. However, as far as I can tell, the SSL certificate for the Rest service requires the FQDN - otherwise it presents the error
There is a problem with this website’s security certificate
Does anyone know how to troubleshoot and work around this problem?
The first error is probably a DNS issue. As that blog mentioned
If you are using a fully-qualified domain name, you need to ensure
that it’s a name that can be resolved within your local network. (In
some cases, customers are running DNS in the local network, and it’s
that local DNS service that resolves the name.)
So, If you have to use FQDN in the connection string for the Hybrid Connection. You could use an FQDN which only could be resolved by local DNS service.
Alternatively, you could try to edit the hosts file to make DNS lookup preferably inside the on-premise network. Add a line in Rest service server hosts file (located in %WINDIR%\system32\drivers\etc) mapping the IIS server's IP to a name.
For example:
192.168.0.50 serverFQDN
More details, Refer to this.
I've got an Azure Virtual Network setup and a VM setup within the network. I've installed the Hybrid Connection Manager app on the VM.
I also have an Azure App Service and I've created a hybrid connection between it and the VM and they are both claiming they are happily connected to each other.
Also on the VM I've installed an app that is listening on http://localhost:1234
Can someone tell me what IP I use from my app service to talk to http://localhost:1234 on the VM? e.g. Is it [VM internal IP]:1234 or [VM public IP]:1234, or something else. Nothing is talking at the moment so I want to make sure the IP address is not the problem.
Just use the computer name of the VM. For example, call to SQLSRV009:1234 from your code in App Service. The Hybrid Connection definition in the portal should reflect the same name (same as computer name, same as what you're calling from your code).
Check out this well written guide for the full picture —
https://learn.microsoft.com/en-us/azure/biztalk-services/integration-hybrid-connection-create-manage
It is possible to set a Hybrid Connection endpoint to an IP address. If you use an IP address, you may or may not reach the on-premises resource, depending on your client.
The Hybrid Connection depends on the client doing a DNS lookup. In most cases, the client is your application code. If the client does not perform a DNS lookup, (it does not try to resolve the IP address as if it were a domain name (x.x.x.x)), then traffic is not sent through the Hybrid Connection.
For example (pseudocode), you define 10.4.5.6 as your on-premises host:
The following scenario works:
Application code -> GetHostByName("10.4.5.6") -> Resolves to 127.0.0.3 -> Connect("127.0.0.3") -> Hybrid Connection -> on-prem host
The following scenario doesn't work:
Application code -> Connect("10.4.5.6") -> ?? -> No route to host
Also make your app listen on either 0.0.0.0 or the private IP since i'm not terribly sure localhost will work with HC.
Why not use VNET integration for the Web App? All you need to do is create a route based (IKEv2) VPN gateway in the VNET, like so —
https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet
You should use VM host name, thanks for evilSnobu's link .
If you use an IP address, you may or may not reach the on-premises
resource, depending on your client.
If you use VM public IP, traffic packets are transmitted over the Internet to your VM not VPN tunnel. localhost only could be used inside VM.
Also, if your app is listening on localhost(127.0.0.1), the service only could access inside your VM. As evilSnobu said, you need modify your service listening on 0.0.0.0 or private IP(like 10.0.0.4). You could check with following command.
For Linux
netstat -ant|grep 1234
For Windows
netstat -ant|findstr 1234
I already did the setup of My web app, made a Vnet Integration, My Virtual network is connected to my Default Subnet that is using My Security Group, in the security group I did the setup of outbound enabling
Source: Any
destination: 201.87.165.102
Service: 443
Allow
And I still receiving the message
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 201.87.165.102:443
Any tip?
Mmm, you don't give enough data to diagnose your issue.
BTW, I assume you did the VNET integration to access some resources running in your VNET. But I don't see why you would need to update your security group in order to allow access to your public webapp. Your webapp should be accessible independently of your VNET.
You need to check a few things in order to find which part is wrong:
Is the app working?
Is it listening on HTTPS (tcp:443)?
Is the public IP you use (201.87.165.102) the right one?
...
I am having a really wired problem with my home laptop.
Below is what I have done:
I have set up my own VPN via AWS.
I added VPN ip address to Azure SQL firewall ip table
By not having VPN, I can connect to Azure easily.
However, once I connect to the VPN, I got error when I try to connect to Azure.
Error message:
A connection was successfully established with the server, but then an
error occurred during the pre-login handshake. (provider: TCP
Provider, error: 0 - The specified network name is no longer
available.)
On the other hand, I can use VPN and connect to Azure SUCCESSFULLY from my office desktop.
I believe this is something to do with my Home laptop settings.
but even I disabled firewall on windows 7,
and after disable firewall on azure SQL as well.
I still having same connection problem
any ideas?
Try opening up the SQL Azure firewall to all addresses to do a test. Maybe when you VPN in, you are leaving through a proxy and so your actualy IP address to Azure is different. You can set up something like:
IP range start: 0.0.0.0
IP range end: 255.255.255.255
If that works, then maybe you can do something with masking your VPN address like:
10.10.0.0 - 10.10.255.255
By not having VPN, I can connect to Azure easily. However, once I connect to the VPN, I got error when I try to connect to Azure.
Some VPNs support co-existence with normal internet connections while others don’t. I am not sure if AWS VPN supports that or not. If not, when you connect to the VPN, you lose your internet connection and thus cannot connect to SQL Azure.
On the other hand, I can use VPN and connect to Azure SUCCESSFULLY from my office desktop.
If the issue is related to firewall setting, you can try to change the setting programmatically, please refer to http://blogs.msdn.com/b/sqlazure/archive/2010/07/29/10043869.aspx for a sample.
Best Regards,
Ming Xu.