1

To start i'm new to Azure.

I've been experimenting with Azure to try and get a basic server up and running with a web server and FTP access.

I initially tried to get a Windows server running with IIS but was unable to access the web server via the public IP address. This was created using Resource Manager deployment model. I tried the same with Ubuntu 14.04 with Apache and exactly the same, I couldn't access the web server via the public IP address. In both cases resource manager model was used. End points were configured for port 80 and on windows the firewall was set to accept requests on port 80.

I decided to try setting up Ubuntu using Classic Model, set the endpoints for port 80 (HTTP) and 21(FTP). Once deployed I ssh'd into the server installed Apache2 and vsftpd.

Once they were installed I went to the public IP address and the Apache page displayed. I tested FTP and that worked.

To check if I'd done something wrong with the Resource Manager model deployment I deployed Ubuntu again using Resource Manager Model, set the same endpoint and installed the same software (Apache and vsftp). When I went to the public IP address there was no response.

Has anyone any idea why Azure works like this and how to get the resource managed model deployment to allow access to resources such as a web server vi the public IP address. Is there another level of configuration that is required for Resource Managed deployments?

Thanks

  • There are several questions around this area. I posted one such answer, describing how to create inbound network security rules, here. – David Makogon Feb 24 '16 at 17:50
2

1) Make sure service is started and accepting requests - use nmap and links:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2016-02-25 00:47 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000050s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

$ links http://localhost

2) Disable firewall for testing purposes:

$ sudo ufw disable

3) Add inbound rules to the Security Group:

Make sure source port range is set to *. A common mistake is to think that the source will use the same port as the destination.

enter image description here

4) Test you web application. It must work because there's really nothing else blocking the connection. Same concept applies to Windows VMs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.