Currently I have a https website setup locally on the Azure VM
with a custom hostname : <websitename>.<domainname>.com and bound to the localhost 127.0.0.2
in the hosts.etc on port 443
Consider example hostname as web.microsoft.com
Website bindings in IIS are
type:https
hostname:web.microsoft.com
port:443
IP Address:127.0.0.2
Hosts.etc
127.0.0.2 web.microsoft.com
In order to access it locally on the VM itself https://web.microsoft.com/admin/login.aspx works fine.
Port 443 is open on the Azure VM and inbound firewall rule is set in windows to allow connections on 443
If I try to access it outside of the network using the public IP address this doesn't work
eg https://45.60.200.110/admin/login.aspx.
I have other non-https websites which work fine and can be accessed through the public IP ,only difference is they are not having hostname in the IIS website bindings.
Am I missing something or do I need to make some additional config?
That's the problem.
The customized hostname cannot be accessed through the external network. Because the public network does not know this hostname, nor does it bind the hostname to your IP.
For example, you can enter other custom host names at will in the browser, and you will find the same error displayed.
The solution is that you need to purchase an available public domain name from the domain name provider and bind it to IP address.
If you insist on using custom domain name, it can only be used on the internal network. In addition to the configuration made on the server side, it is also need to add the host name and IP address in the hosts file of the client machine.
45.60.200.110 web.microsoft.com
Related
I have created a virtual machine in Azure and enabled the IIS role.
I have created the appropriate firewall rules to allow me to browse to a website that I have set up in IIS over HTTP.
However, despite having created the bindings and firewall rules to enable HTTPS, I am unable to browse to the same website over HTTP.
I have been reading that I need to create a HTTPS endpoint for Azure to traffic any requests on port 443 to my site.
Does anyone know how to do this in the new portal?
Thanks,
Sean
By default, when you create a VM, only port 3389 (RDP) is opened. You will need to add any additional ports that you need to the Network Security Group.
Here is an example of how to add an NSG inbound rule to allow traffic on port 80 (HTTP), but you can use the same steps to allow traffic on port 443 (HTTPS):
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/nsg-quickstart-portal
Ok, so I have got this working so I will document the steps that I went through in order to get this to work:
Create a public IP address in the Azure portal
Assign a ‘cloudapp.azure.com’ DNS name to the IP address
Associate the IP address to an Azure network interface (this network interface may be attached to a VM or an App Service – in our case, it’s a VM)
Create an http endpoint in IIS and set the host name in your bindings to the ‘cloudapp.azure.com’ DNS name and the the IP address to the IP address created in step 1
Create a https endpoint and select your wildcard server certificate as the SSL certificate
Create a ‘CNAME Record’ entry in your DNS Configuration where the host is your custom DNS name and the target is the Azure DNS name
Open a web browser and browse to your custom DNS name via https and ensure that the website displays the server certificate
I have a registered domain name, www.aaaDomain.com, assigned to ip address xx.xx.xx.xx . I set up my site on IIS8 to use the ip address xx.xx.xx.xx and port 8020 for my website. I can connect to the website when I type xx.xx.xx.xx:8020 in a browser but I cannot connect to the website when I use www.aaaDomain.com:8020
Also, I have another website on this same server as my Default website. When I type just the domain name without the port number, my default website comes up (because DNS does not allow adding port numbers) just like when I type in the ip address without the port number.
What am I doing wrong?
Here is what my site binding looks like on IIS8.
As you already have an existing site running on the server you should check your security settings on both the Windows firewall and any other security/firewall settings you have - It sounds like you have not opened the additional port which you have just configured in IIS.
Check to see if you can ping the new site by its domain name - that will verify that you have the correct DNS setup, you can also try & browse to it via the server console (or remote desktop) if that works then its security setting somewhere blocking your access. Even if the ping request times out it should still resolve the name to an IP address for you to check. You may find that ICMP is also blocked.
If you just changed your dns record, be aware that you should wait up to 72 hours for the dns to replicate after changing your dns record.
I've got a app plan (BASIC SMALL) with a private (hopefully) ip adress that can be found under Settings > Custom Domains.
When I try to access the content of the app using just the ip, it doesn't work. The site says "Error 404 - Web app not found." The hostname works just fine. When I ping the hostname it gives me the same ip adress. What do I have to do in order to be able to access it just using the ip?
That's not how Web Apps work, since you don't get a unique IP address assigned. You'll need to access it via yourname.azurewebsites.net or yourcustomdomainname.com - and then your requests are routed appropriately based on the name you provide.
If you absolutely needed a dedicated IP address, you'd need to deploy to a virtual machine.
When you host your web site on Azure web app it is bound to a virtual IP address that is shared with other web sites in the same app service plan. If you want to get a dedicated IP with your web site, please try to use Azure virtual machine with reserved IP. You could also choose App Service Environment
If you buy your custom domain, you can freely set DNS A records for that IP (it remains static). It sets binding of your domain to your web app. You can't access it directly by IP. Because on a given IP address and standard HTTP port 80, only one web can be running.
Imagine your web app could be open by entering that IP. You would "block" port 80 for zillions of other stuff running there.
If you check Properties blade there you will see a number of outbound IP addresses. If you consume some requests from web app / job / ... and have IP restriction set on the other side - you need to allow all these IPs.
As David suggested. If you really need a static IP - you need to run VM and set IP address as static or set VNet for web app.
I know this may be very basic, but I have a website on my server that I would only like to be accessed by VPN. I have OpenVPN running on my Windows machine and it is connecting to my server with the VPN. When the VPN connects I can use the VPN's IP address to hit the site on my server. I would like to block all other methods such as the actual site IP or my domain name. Would I use htaccess? What is normally done for private access only.
Let's say that your server vpn ip is 10.1.2.3 then you should add to your apache configuration
Listen 10.1.2.3:80
so that you will bind Apache - i.e. will accept incoming requests - only to that address.
Also:
The Listen directive does not implement Virtual Hosts - it only tells
the main server what addresses and ports to listen on. If no
directives are used, the server will behave in the same
way for all accepted requests. However, can be used to
specify a different behavior for one or more of the addresses or
ports. To implement a VirtualHost, the server must first be told to
listen to the address and port to be used. Then a
section should be created for the specified address and port to set
the behavior of this virtual host. Note that if the is
set for an address and port that the server is not listening to, it
cannot be accessed.
i.e. you could leave the original listen directive (listen to all interfaces) and filter the access per virtual host having your "private" virtual host configured like that:
<VirtualHost 10.1.2.3:80>
see http://httpd.apache.org/docs/2.4/bind.html
Finally if for some reason you are restricted to .htaccess only, then you could do in .htaccess:
Order Deny,Allow
Deny from all
Allow from 10.1.2.1/24
i.e. allowing access only from your vpn subnet.
Take care that you will need to restart the web server after every change.
We are installing a security camera system in our company which comes with a DVR that hosts a website on which you can view the cameras via the web.
I have setup the DVR with a static IP of 192.168.120.199 on our network and can view the website while on our network (either when at work or logged in via VPN). The camera DVR uses port 80 for viewing the webpage and port 9000 for Media Port.
We use GoDaddy to host our DNS info and I have added an Host(A) record of 'cameras' that points to the address of our server. I have also added a forward lookup Host(A) to our domain's DNS manager of 'cameras' that points to 192.168.120.199. When I use the address 'cameras.mysite.com' within our domain the website displays properly, but when I try the same address from outside our domain (ie, at home) it displays the default IIS 7 page (from our domain server).
Two questions about this setup:
Why does the forward lookup work when inside our domain but not outside (why does it go to the IIS default page when outside the network)?
How do I get this to forward correctly if not via the forward lookup host?
Because internally you're looking it up on your internal DNS server and you get the right 192.168.x.x machine. When you look it up externally GoDaddy is giving you back the 192.168.x.x, but that's not a publicly routable IP, so doesn't go anywhere. If you really want to be able to connect to your security cameras from outside your facility then I suggest setting up a VPN for security reasons. But if you want GoDaddy to directly route to your internal machine from the public internet then you'll have to give it a publicly routable IP.
As a further note on that - 10.x.x.x, 192.168.x.x and 172.16-31.255.255 are not publicly routable. They're called private IP blocks.