It seems like the solution to my problem should be easier than it is, which makes me think I'm missing the obvious. I'm trying to test and ensure that a remote client machine can send/receive messages from an Azure Service Bus Queue.
I'm using the sample application provided by Microsoft at https://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-amqp/
The sample application works perfectly fine as long as all ports are open. However, I need the solution to work when only ports 80/443 are available. If I configure Windows Firewall to only allow inbound/outbound traffic on 80/443 it doesn't work. I receive the error "An attempt was made to access a socket in a way forbidden by its access permissions".
The offending line from the sample application is:
sender = factory.CreateMessageSender(entityName);
I've looked at an extraordinary number of sites and one of the suggestions I've found was to set the connectivity mode to Http such as this:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
That doesn't work either.
I'm not trying to setup custom services on either the remote client or Azure hosted roles. I just need them to both be able to send/receive messages via Azure's Service Bus Queues and Topics.
Can anyone point out my flaw?
From my comment above...
I found the answer to why it's not working in my case. The preview library for AMQP in Azure uses a different port then all other documentation I can find. Using the release library it works over https automatically.
Http Connectivity mode doesnt work for Http 1.0. It will work only on Http 1.1...
If you are in Http 1.0 (mostly proxy) you have to open TCP ports (9350-54)
Related
We have an Azure set up where we use Azure as our proxy for sending data to our apps via Azure functions.
We are having issues because evidently our local development Windows environments send the calls to Azure, and we verify this by logging into our Azure portal, and watching any traffic to the calls in the Azure function console. When we run our code on our local machines, we see the traffic and the calls getting made, BUT when we try the same calls on our production server environment (hosted onsite, Windows Server 2016) to Azure, we can't see any traffic come through our Azure calls.
I am trying to chase down whether it is the Firewall on the production server machine and to see if there are any Outbound Firewall rules that need to be opened up or added to talk to Azure, but I have not seen anything by doing my Google searches that brings up local machine talking to Azure. Most of the articles that come up are about setting up a Firewall on Azure, not local firewall rules to Azure.
The application we are running is an onsite IIS hosted website with calls out to Azure.
Anyone have any pointers on where or what I should be looking at to see if there is any communication coming from our production server to Azure on the production server. Which logs, rules, anything that could point us in a direction. I felt I have looked in most places. I have looked in IIS logs, application logs (we just send a log saying that the call was sent)
But if there is a specific Firewall setting on the produciton server that I need to add, I don't know what that would be and if anyone does know, it would be very helpful.
UPDATE:
We have so far found that we can hit the functions through a browser enabling GET requests and other functions that allow GET requests. The issue seems to be either IIS or a permission with IIS or the application itself. We actually set the permissions on our application on our server to "Everyone" just to see what would happen, on the folder for the application and still have not have any luck. The calls we are calling are actually POST to the Azure function. We don't have Postman on the machine.
Assuming you're calling out to an Azure Funciton, which is not running on an App Service Environment, or behind API management or similar, then the only place you can restrict access is on the networking tab of the settings of the function. If you don't have this configured then the function is not where the issue is.
If traffic outbound from your on-prem server is being blocked, then you will need to talk to your IT team to get that opened up. You don't mention how you're calling your funciton, but if it is an HTTP trigger, then you would need port 443 outbound open.
I'm trying to access a third party service from Azure App Services (ideally Functions, but a Web App would do). However this service is hosted on a non-standard port, e.g. https://myservice.com:445
I'm using the System.Net.Http.HttpClient to make a POST request, but consistently get a SocketException:
An error occurred while sending the request. Unable to connect to the remote server An attempt was made to access a socket in a way forbidden by its access permissions 1.2.3.4:445
The code works on my local environment (Functions emulator or Kestrel), but fails on Azure. I tried using a service hosted on a regular https endpoint, e.g. https://myotherservice.com, and the call goes through normally.
I'm assuming there is some sort of outbound firewall rule that's preventing the fist call, but I haven't found any configuration option to disable this. Is it possible? I unfortunately cannot change the endpoint of the service I need to call.
After checking your application, I did indeed find that those outgoing requests were being blocked by the infrastructure.
I was also able to find public documentation covering those ports here:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#restricted-outgoing-ports
We have a setup where we have both VMs and Web Apps in Azure connected to our on-premise resources via a point-to-site virtual network.
We have an folder on premise with access to Everyone open (both on the share and NTFS) and the Azure VMs that are on that virtual network are able to browse to the share without difficulty.
The web apps are not able to access them however.
I'm assuming the following line in this article explains the reason, but I'm looking to confirm this is not possible:
The work required to secure your networks to only the web apps that need access prevents being able to create SMB connections. While you can access remote resources this does not include being able to mount a remote drive.
Coming out of the logs from the attempt from the website to access it:
Taking the C# code out of the picture, trying to get the directory listing from the powershell console on the web app:
I've also tried this with Hybrid Connections, and am getting closer - once it's setup and attached to the Web App, I'm able to tcping the SMB port from the powershell console (which is further than I can get when using the VNET), but it's still unable to list a directory:
Any thoughts? Anyone doing anything similar?
The tcping result is actually misleading - you are really pinging a local port hosted on your web app (hence why the tcping has results of ~1ms). Tcping doesn't actually test the full tunnel for Hybrid Connections because the tunnel is a TCP level data relay only (that is, it does not send TCP headers, etc., over the tunnel, only payload) and tcping does not send any data, only simply verifies that the TCP handshake succeeded.
Unfortunately, the article is correct - SMB will not work at all in your Web App. There are security layers in place that will block the attempt.
I have setup FTP in IIS 8.0 on an Azure windows server 2012 virtual machine.
After followed the instructions in this post (http://itq.nl/walkthrough-hosting-ftp-on-iis-7-5-a-windows-azure-vm-2/) I've been able to make FTP work fine in passive mode, but it fails when trying to connect in active mode from FileZilla. FTP client can connect to the server in active mode but fails with timeout error message when trying to execute LIST command.
I carefully revised 20 and 21 endpoints are set in azure vm without pointing to a probe port and that windows firewall allows external connections to 20 and 21 VM ports.
I can't figure out why active mode doesn't work while passive mode works fine.
I know there are other users with some issue.
Please is there someone who had succed setting active ftp in azure VM?.
This previous response is incorrect. https://stackoverflow.com/a/20132312/5347085
I know this because I worked with Azure support extensively. The issue has nothing to do with the server not being able to connect to the client, and my testing method eliminated client side issues as a possibility.
After working with Azure support for 2 weeks, their assessment of the problem was essentially that “Active Mode FTP uses a series of random ports from a large range for the data channel from the client to the server. You can only add 150 endpoints to an Azure VM so you couldn’t possibly add all those ports and get Active FTP working 100%. In order to do this you would need to use “Instance level public IP” and essentially bypass the endpoint mechanism all together and put your VM directly on the internet and rely entirely on the native OS firewall for protection.
If you HAVE to use Active Mode FTP on Azure and are ok with putting your VM on a public IP, he provided this link:
https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/
UPDATE: Official response from Azure Support:
Josh,
First of all thanks with your patience on this. As I mentioned in my
last email I was working with our Technical Advisors which are Support
Escalation Engineers on reproducing this environment in Azure. Our
tests were configured using WS_FTP 7.7 (Your version 7.1) and WS_FTP
12 client as well as the Windows FTP client. The results of our
testing were the same as you are experiencing. We were able to log in
to the server, but we get the same Command Port/List failures.
As we discussed previously Active FTP uses a random port for the data
plane on the client side. The server connects via 21 and 20, but the
incoming port is a random ephemeral port. In Passive FTP, this can
be defined and therefore endpoints can be created for each port you
use for part of the data plane.
Based on our extensive testing yesterday I would not expect any other Active FTP solution to work. The escalation Engineer that
assisted yesterday also discussed this with other members of his team
and they have not seen any successful Active FTP deployments in Azure.
In conclusion, my initial thoughts have been confirmed with our
testing and Active FTP will not work in the Azure environment at
this time. We are always striving to improve Azure’s offering so
this may be something that will work in the future as we continue to
grow.
You will need to move to a passive FTP setup if you are going to host
this FTP server in Azure.
When using active ftp, the client initiates the connection to port 21 on the FTP server. This is the command or control channel and this connection usually succeeds. However, the FTP server then attempts to open port 20 on the client. This is the data channel. This channel is used for all data transfers, including directory listings.
So, in your case, active FTP isn't working because the server can't initiate a connection to the client. This is either a problem on the server (outbound firewall rule) or on the client itself. This is usually a good thing because you don't want internet-based servers to be able to open connections on client machines.
In passive mode there is a clear client/server distinction where the client initiates connections to the server. Passive mode is recommended so if you got that working I'd stick with that.
I'm using some hosted 2008R2 servers for testing scenarious in the Azures cloud and they seem to be working well for most things.
I need clients to directly access the server via VPN such that they have full IP access to the server, for, say, SMB NET USE drive mappings, which otherwise would not be available over the Internet.
Normally, you'd just install RRAS and configure VPN.
But on these VMs, the connection from a remote VPN client fails. I'm forwarding the correct endpoints (I believe), 47 & 1723 for PPTP and 50/51/500 for IPSEC. But they aren't getting through.
The server is listening on these ports.
All my searching seems to suggest you need to use "Azures connect" for VPN access, so does this mean you can't go direct to the server for clients? I don't want to go for the Azures Connect route as I'm just playing/testing and don't want to use any proprietory methods.
Confirmation that this is impossible would be useful to save me going mad.
Azure Connect is a very good way to start; it is an Azure service so I am not sure why you are reluctant to use it. I would keep an eye on performance; VPN could very well be faster. Here is my blog post on how Azure Connect works and the steps I took to make it work: http://geekswithblogs.net/hroggero/archive/2012/10/18/how-to-create-a-virtual-network-with-azure-connect.aspx
Regarding VPN, only certain devices are supported for the preview. Please refer to MSDN for a complete list of supported devices and protocol requirements: http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx