I have access to a server behind a corporate firewall. I need a web application on it to talk with https://westeurope.api.cognitive.microsoft.com/vision/v1.0/ocr. The infrastructure department want an IP number to that service, so they can open up a hole in the corporate firewall, so the application is allowed to make the out-going call. If I do an 'nslookup westeurope.api.cognitive.microsoft.com' I can see the receiving IP is 13.93.122.1 - but will it always be so... Is there a range I should know, or can I be certain that the Microsoft IP remains static?
Related
We have a few Web Apps that need to access database on VM that behind Network Security Group. How do we allow Web App through Network Security Group?
Web App will use a set of outbound Public IP addresses to reach Internet. You can get those IP address by navigating to the Properties of the Web App.
In your NSG, you can use the Source IP as the list of IP that you got from Properties blade to allow traffic to your database. Also make sure to only open the port used by the database, and nothing else.
I am more a C# dev than a network admin and I am not understanding what happened.
I have a website hosted on an Azure Web App and I started to get a lot of repetitive requests from IP address 172.16.5.1, to a point that it affected the web server stability
The only way I found to fix the problem is to block this IP address, but I still have questions.
1) Is blocking the IP the best solution to the problem?
2) After googling, I found that this IP address is in the range of Private IP addresses. How can a private address reach my public web server?
3) Could it be another resource from my Azure subscription that could be making these requests?...I only have a web app configured so I don't know where these requests could come from internally
4) Can this be a DDoS attack?
This IP Address is private range as you found it, but needs more information to answer your couriosity.
I could say that’s not the best solution, you need to find out which resources on your Azure that use that IP and see why it sends a request to Web App.
This is possible when your Web App connected to the Virtual Network, discuss with your Network Admin or System Architect.
I’m quiet sure that your Web App is connected to Virtual Network or could be another instance of your Web App requesting each other.
I’m not quiet sure that was an external DDoS attack.
That appears to be the default gateway for a subnet. Check the Networking blade to see if you are integrated with a VNet. I would expect that probes from something in the VNet (AppGW, Azure Firewall, NVA, etc.) would come from the instance IP of that resource and not the default gateway, but you really need to see the subnet range and know what's in there. If this is a WebApp that is integrated with a VNet via point-to-site VPN, then maybe this is something from the VNet Gateway, like Keep Alives. That might be apparent in a network trace. Blocking that IP could result in some other service marking the WebApp as unhealthy and not routing traffic to it.
Lots of conjecture here, but like Rudy said, you're not getting an external DDOS attack from a private IP.
I've been trying to find an answer to this for a few days.
I want to host a new azure website in either the Basic tier or Standard tier.
The site will be calling a third party service.
I need to give this service provider an IP address that they will whitelist.
So when the new azure website makes requests to this service the IP address for the request needs to always be the same, as this will be the IP whitelisted.
I read that Azure offers "Reserved IPs" for cloud services and VMs but I wanted to know if something similar can be done with Azure Websites as I really don't want to go with cloud/VM.
My knowledge of networking is limited but as I understand it, if I were to get an IP SSL cert and apply that to my Azure Website then the website would have a static IP address.
If that is the case, would any requests to the third party service be hitting the service providers external firewall with this same static IP?
Thanks for any advice people can give.
An SSL cert with Web Sites will be tied to an inbound IP address. However, Web Sites does not provide a static outbound IP address.
If you need a static IP address to align with 3rd-party services, you'd need to have something residing in Azure (e.g. Application tier) running in a cloud service / VM that your web site accesses, and then have that app tier (with static IP address) communicate with your 3rd-party services.
As David Makogon's answer points out, applying an IP-based SSL certificate only gives the website a static inbound IP address.
However, the outbound IP address a website uses when making outbound network calls can be determined based on where your website is hosted. Microsoft has a list of the these IP addresses here. The third-party service would have to whitelist all of the IP addresses used by the scale unit your website is hosted in (e.g. waws-prod-am2-005).
Correct me if I am wrong, but the information shared by Brant Bobby above shows that, in fact:
All Azure websites (/Web Apps) already have a discoverable and published outgoing IP address.
This outgoing IP address will never be unique to their own site however. So one must keep in mind if they use it for a white-list, it will be allowing in a lot of other Azure visitors hosted on the same scale unit.
Simply get the so-called "scale unit" name for your site, which is the same as what's given in your site's FTP address (and so forth), which is in the format: "waws-prod-[3LetterVar]-[3DigitNum]", e.g. waws-prod-blu-007.
As an example from that article, all the East US region Azure websites can find the four IP addresses their site may rely on as follows (so if white-listing, all 4 should be white-listed):
East US Region
Outbound IP addresses for each scale unit, currently 4 for each. They said they may add more IPs to each scale unit in the future, but these should not change.
waws-prod-blu-001: 168.62.48.13, 168.62.48.19, 168.62.48.33, 168.62.48.122
waws-prod-blu-003: 137.117.81.128, 137.117.81.142, 137.117.81.181, 137.117.81.82
waws-prod-blu-005: 137.117.80.189, 137.117.81.52, 137.117.81.90, 137.117.80.178
waws-prod-blu-007: 23.96.33.205, 23.96.34.196, 23.96.35.20, 23.96.36.229
waws-prod-blu-009: 23.96.97.203, 23.96.97.233, 23.96.97.235, 23.96.97.238
waws-prod-blu-011: 23.96.112.60, 23.96.112.117, 23.96.112.152, 23.96.112.15
waws-prod-blu-013: 191.238.8.154, 191.238.9.80, 191.238.9.94, 191.238.9.170
waws-prod-blu-015: 191.236.19.222, 191.236.19.242, 191.236.21.165, 191.236.18.160
waws-prod-blu-017: 191.238.32.104, 191.238.32.154, 191.238.34.67, 191.238.35.12
waws-prod-blu-019: 104.45.138.197, 104.45.142.87, 104.45.128.144, 104.45.142.131
waws-prod-blu-021: 191.237.24.189, 191.237.30.36, 191.237.26.164, 191.237.28.161
waws-prod-blu-023: 191.236.50.206, 191.237.30.215, 191.237.25.148, 191.237.22.195
waws-prod-blu-025: 191.237.31.86, 191.237.26.176, 191.237.20.70, 191.237.18.239
Azure now supports having static outbound IP address as well.
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
If we do not want to go for costlier App Service Environment setup, we can directly use the outbound IP addresses mentioned in the Azure portal in properties section, Azure assures that it remain 99.9% static. Nothing really changes until there is some changes data center wide. Moreover, the reserved Ip what we use in IaaS is also not 100% reserved for us and azure provides SLA of 99.9% here as well. So, In my opinion, instead of going for ASE and hosting IaaS and using reserved IP, we can just use outbound Ip provided by azure, since we get same reliability in both cases.
I would like to use my internal exchange servers for email notifications from an azure Web Role. The role is set up on the west us region. I need to allow this role, with multiple instances, access my corporate smtp server on port 25. IS there an appropriate range of IPs that I could open up on my corporate firewall, or is there a more secure option.
We have experience setting up networks in Azure as well as VPN gateways, I am not sure that this would be part of the solution as my understanding is not broad enough to see how I could implement something that would allow secure access to corporate networks while continuing to be publicly available.
Any help or direction would be appreciated.
Thanks
Your web role has a single (and fairly static) ip address of the load balancer, but this is of no use to you as the source ip address for outgoing data will be the ip address of the particular instance. You can get hold of this address, but not easily, and it is subject to change — every time an instance recycles, or is added, the ip address will change (although the incoming ip address, of the load balancer, remains static). So you can't provide instance public ip address ranges for the corporate firewall.
If you are familiar with VPNs and private networks on Azure, then that will be your simplest option. Your worker role ip addresses will still change, but the range is more predictable, and is defined by your subnet configuration. A worker role on a private network (VPN) will have both public and private ip addresses, so will be publicly accessible, but will send to a VPN ip address via the gateway.
Another option is to do some sort of smtp relay, either on a VM in Azure, or a managed hosting service, where the ip address is more static. This would require that a machine is setup, maintained, and running, but could probably be easily done on an extra small linux vm.
Your web roles will be part of an Azure Cloud Service. That cloud service is assigned a static public IP address by Azure. No matter how many roles you add/remove from the service the public IP will remain unchanged. You can set your SMTP server to only allow requests from that IP address.
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.