I am trying to connect my custom domain (in my case it's through Godaddy) to my Azure web app.
I have followed all the steps but I am missing the web app IP address to complete the process.
The tutorial found in Azure says:
To create an A record, you need the virtual IP address of your web app. To get the IP address:
In your browser, open the Azure Portal.
Click the Browse option on the left side of the page.
Click the Web Apps blade.
Click the name of your web app.
In the Essentials page, click All settings.
Click Custom domains and SSL.
In the Custom domains and SSL blade, click Bring External Domains". The IP address is located at the bottom of this part.
...everything works well until the last step (#7). I see no "Bring external domains", nor any IP address.
Under "Properties", there is a section OUTBOUND IP ADDRESSES, that contains 4 IPs. None of them seems to redirect to my site (http://educa03.azurewebsites.net/).
How can I find this IP address needed for the A record?
At some point it seems that a bug crept in that has made the incoming IP address disappear from that page.
If you are on a plan that supports domain names, then the best way to find your external IP address is to ping it.
e:\PS>ping educa03.azurewebsites.net
Pinging waws-prod-am2-051.cloudapp.net [104.47.137.62] with 32 bytes of data:
So in this case your external IP address, that you can put in A records, is 104.47.137.62
Any chance you're using a free tier app? if so, you need to upgrade to at least "Shared" to map the custom domain.
Related
I have 2 separate webapi apps and I want the 1st one to be a normal webapi app which can be accessed by any authorised over the internet. With the 2nd one, I need it to not be publicly accessible and only available to the 1st (so the 2nd app is 'nested' within the first somehow).
Could anyone please tell me how I can achieve this (the apps are hosted in IIS Express at present but will be in iis for production)?
Many thanks
If you're concerned about security (and everyone should be), you can configure IIS to allow only specific computers, groups of computers or domains access to your Web site. Here's the procedure:
1)Open the IIS console and go to the Properties of your Web site.
2)double-click IP Address and Domain Restrictions.
3)Click Add Allow Entry... (on the right pane) to add an IP address or IP address range which will be allowed to access the website. Click OK.
Repeat this step to add other IP addresses to the list.
Once allowed IP addresses have been added, click Edit Feature Settings... and select Deny for Access for unspecified clients. Click OK.
Now, only users with the specified IP addresses are able to access the website.
Have one app service plan (standard 1 pricing tier) with only one web app. From what I understand I have a static ip based on this configuration / price. So when I do an nslookup on my web site and get an ip back, that ip is static correct? Just needed verification. TIA.
So when I do an nslookup on my web site and get an ip back, that ip is static correct? Just needed verification
Every Azure Web App have 1 external IP address and multi outbound addresses. What you saw from nslookup is external IP address.
The external IP address(Inbound address) is used for domain binding(A record binding). If you want to binding your custom domain, please use external IP address. You could find the external IP address from Azure portal. Web App->Custom Domains tab.
From official document, we know
If you delete and recreate your app, or change from a higher pricing tier back to the Shared tier, your app's external IP address may change. Otherwise, the external IP address won't be changed.
Traffic come from your web app will use one of the outbound addresses as IP address. There is no agreement of when the outbound IP address will change or not. They will not change from 1 day to the next, nor is there any plan or real need to change them.
will there be some type of notification from azure when the outbounds do change?
There is no official document which pointed it out. I found following words from MSDN forum. Hope it will be helpful for you.
It becomes necessary for Azure infrastructure to increase the number of outbound IP addresses. In that case the existing IP addresses will be preserved but there will be some new ones. So far there hasn't been a need to increase number of IP addresses and if there ever be the need for that there will be an early notice about it.
The Web App gets relocated to a different scale unit. Prior to that the subscription owner gets an email notification one month in advance.
From: Static outbound IP addresses for Azure Web Apps?
I'm pretty sure you are assigned 4 external IP addresses, so at the very least there are 4 ip addresses you need to consider static, but from what I can tell they are subject to change (that's how it previously was, I'm not sure if it holds now).
Also, remember that those are shared, so whitelisting those is potentially dangerous.
I got lost with Traffic Manager setup and custom domain name.
First I had two mobile apps in 2 regions (westeuropeapp.azurewebsites.net and brazilapp.azurewebsites.net) as endpoints of Traffic Manager (trafficmanager.trafficmanager.net). It was Working.
Then I wanted to use a custom domain name with subdomains: westeurope.mydomain.com, brazil.mydomain.com and trafficmanager.mydomain.com. So I followed Azure doc instructions and created CNAME for my subdomains pointing to the two mobile apps and to traffic manager. Then I added westeurope.mydomain.com (resp. brazil.mydomain.com) as hostname for my west europe mobile app (resp. brazil mobile app).
But when I navigate to trafficmanager.mydomain.com I got a 404.
I checked the DNS resolution with Dig, I can see that trafficmanager.mydomain.com has a cname to trafficmanager.trafficmanager.net which has a cname to westeuropeapp.azurewebsites.net which resolve to ip xxxx.This looks good.
If I type that ip into my browser I got 404. But if I type westeuropeapp.azurewebsites.net I got my app running. I also checked westeuropeapp.azurewebsites.net in Dig and it resolves to the same ip as above.
What am I missing? (I don't even talk about SSL, it will be next post.)
You also need to add trafficmanager.mydomain.com to the Mobile Apps as a custom domain.
App Service shares IP addresses across apps, so the only way for it to identify which app your request is bound for is the Host header. By adding the custom domain App Service knows to route requests for that domain to that app.
Once you add the mobile apps to the traffic manager, trafficmanager.mydomain.com will automatically gets added to the mobile app, in the host name assigned to site(App->Custom domain). Wait for sometime for the changes to propagate. After the trafficmanager is propogated, You need to add custom domain to both of your mobile apps.
This video has the details for adding custom domain for the traffic manager. https://www.youtube.com/watch?v=1ggz9qZpVHo
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've entered the IP address from the Windows Azure Portal (both the one specified in the website Dashboard or within the Manage Domains area) but when trying to use SagePay Direct it returns that it is not a valid IP address.
I eventually solved this by doing a "showpost" for SagePay and then having to tell me what the IP address is.
The problem is - how can I determine this IP address for myself? As I worry that the IP address could change in the future.
If I use "Request.ServerVariables("LOCAL_ADDR")" (Classic ASP) it seems to return the local IP address of the webserver.
what if you create a script or something that just returns the visitor IP address and make a request, get or post, to that script from your server?
The IP Address that you see to use for your A records is not the outgoing IP Address used by Azure Websites. Hence why SagePay does not accept transactions from the website because it is an invalid IP Address.
Instead there are 4 IP Addresses that you need to add, and those 4 IP Addresses depend on what Scale Unit your site uses.
The scale unit for your site can be found from the FTP Host Name for your Azure website. For example: ftp://waws-prod-blu-011.ftp.azurewebsites.windows.net - the scale unit is 'waws-prod-blu-011'
I then put that into Google, and a couple of azure maintenance articles came up. Scroll the article to you see your region, and then your scale unit and there are the 4 IP Addresses you need.
Please refer to this azure maintenance article for more information.