I have a requirement where I need to host an FTP server along with a website that is hosted on Azure Web Sites. We host separate instances of this app for our clients - and it needs an separate FTP server per instance
The solution that I'm trying currently is using the FubarDev.FtpServer. My plan was to host that FTP service in a web job.
Launching the FTP server seems ok. The Web Job prints out a line to web job console after the server is started, status is of the web job is running and no exceptions are output.
Now, trying to connect to the FTP fails. I suspect the reason is that the port 21 is not open on the firewall that protects azure websites and no traffic on that port is forwarded. Is there any way around this?
Connecting from the Website it self to the FTP server hosted in the job gives the following errors:
When connecting to 127.0.0.1
An attempt was made to access a socket in a way forbidden by its
access permissions 127.0.0.1:21
When connecting using the websitename.azurewebsite.net on port 21 (from the website itself, that is hosting the FTP inside the webjob)
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 xx.xx.xx.xx:21
I would like to stick to the Azure Web Apps as much as possible to avoid having to manage VMs
Any help would be greatly appreciated! I'm also open to the potential alternative approaches to this problem.
Azure Web Apps only support incoming traffic on ports 80 and 443. You will not be able to host ftp servers via web apps (aside from the built-in ftp server). You'd need to place the ftp server either in a VM or web/worker role (cloud service).
Related
I have an Azure app service and in some cases I need to send a web request to a non-azure webserver. What do I need to do to make it possible.
Currently the web request fails with no clear error message.
In response to a HttpClient Put request I get a System.Net.WebException exception which says there were errors.
THe same request works from a desktop application.
If your webserver is reachable from the internet you should be able to access it through your App Service. Try to log a ping to your webserver and google (8.8.8.8).
If your App Service is in a VNET you should enable some outbound rules to your webservers IP adress.
The server I am connecting to is an other Azure service. After some more investigating, It appears that I can connect to it if I do not use SSL (i.e. http://) but the connection is immediately closed when using SSL (https://). I assume that the problem must be related to the use of SSL.
I have an Azure virtual machine, on which a process listens on a certain port. A Node.js application on my local computer is able to connect to this process using the VM's public IP address. But the same Node.js application, deployed as an app service on Azure, is apparently not able to connect using any IP address, despite the fact that the VM allows all incoming traffic on all ports.
(Details: The VM process is running "q" (kdb+), and the Node.js application is using the "node-q" package to connect to it. Both the Azure VM and the Azure app service are Linux, but the local version of the app service is on Windows. The Azure app service is able to connect to my Azure SQL database.)
Any insights into this problem would be appreciated.
There are many reasons for Bad gateway error, probably you could verify these factors on your side:
Azure VM side. Make sure the Azure VM is running and the process port is listening when you request a connection from an application. You could run sudo netstat -plnt on Linux VM to check the listening ports. Or, a server can crash if it has exhausted its memory, due to a multitude of visitors on site or a DDOS attack.
Firewall blocks a request. You should allow all incoming traffic or Azure web app service outbound traffic on this listening port on the VM. In this scenario, you could verify the Network Security Group configuration for the VM and firewall inside the VM if you have. You could find NSG settings by clicking Virtual machine--Settings---Networking---inbound port rules on the Azure portal.
Faulty programming. It seems the Node.js application could work locally.
Temporary issue. Sometimes, there is no real issue but your browser thinks there is one thanks to an issue with your browser, a problem with your networking equipment, or some other reasons. You could refresh your web browser or clear cache and cookies to get the page back what you are looking for. More details you can refer to fixing 502 error.
If you still have any question, feel free to let me know.
It was faulty deployment. I didn't include all dependencies in the upload to Azure. Thank you.
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 am trying lock down a virtual machine that acts as an app server for a web application. I have a two VM's: One for the app server and another one running the web server. I have to open a ton of ports to allow the web server talk to some wcf services, but I only want to allow those connections from the web server and no one outside of that network. I have to add endpoints in order for the web server to access the wcf services, but this also makes them accesible to the public IP. How can I only allow this traffic on the
For Virtual Machines, the only way of accessing ports from outside the hosted service is by defining input endpoints (with or without load-balancing across a set of machines). In your case, you'd just open, say, 80 and 443, specifically for your web server (e.g. not load-balanced). This is considered a port-forwarded endpoint since traffic on these two ports get forwarded directly to your web server. For more clarity around port-forwarded endpoints, I suggest Michael Washam's blog post, here.
At this point, you'd open various other ports on your app server (through its firewall config), and now your web server can talk to the app server, yet the outside world won't be able to reach the app server. Note: I'm assuming you placed your web server and app server in the same hosted service. Otherwise, you'd need to find a different way to connect between web and app servers, such as configuring a Virtual Network.
EDIT 6/5/2013 You can now enable ACLs on input endpoints, allowing (or blocking) IP ranges. Today ACLs may only be managed through PowerShell, with the June 2013 update. See this post to learn more.
Machines that exist on the same virtual network will be able to talk to each other as long as the local firewall has been opened to those ports. This problem was with my configuration in my application and not because of this. I also didn't have the correct ports open. Now it works like a charm.
I am developing a web app that is not doing anything fancy. The parent company wants to use a cloud based IIS service to support the web app and then submit the information to the client's local SQL servers through the internet and the client's firewalls.
Traffic isn't that much of an issue, we are talking about probably no more than 10 submissions daily per client. My question is with regard to connecting to the client's SQL servers and running the Stored Proc on each server.
We already have admin privileges on the firewalls and servers to do what we need to do to make anything happen.
What would be my best/reliable/secure method to implement this service?
Page asks for 10 items of info then submits to Stored Proc, that's it... with a local IIS server there is no problem, works nice. I want to make sure that the information stays secured, not just for the 10 items, but the SQL server and any security between it and the IIS server.
Any recommendations?
I would recommend setting up a VPN tunnel between the remote IIS server and the in-house SQL server. With a VPN tunnel, the SQL server is just like any other server on the network to the app.