Document URLs necessary to configure corporate firewalls
Some companies block access to websites using their firewall and need to white-list specific URLs in order for the portal to work. Common errors that indicate firewall configuration issues include:
"Some subscriptions couldn't be retrieved"
The portal uses cross-origin resource sharing (CORS) to communicate to back-end services directly from the browser. We are working with our partner teams to get a full list of URLs required to manage your resources in the portal. Here are a few known URLs:
Please let us know if we missed any.
Is this still undocumented, all this time later?
Jan V. commented
To whitelist, it would be helpful to have information on the URLs used by extensions or azure services (mapping URL to extension/service). In that way, at least we can document and know why they are opened in the first place. Above, grouping in domains preferred over IPs/subnet as well (which regularly change).
Due to security concerns and protocols we are not able to add the below URL's to our firewall rules:
• *.servicebus.windows.net(Port 5671)
Without these Azure ADConnect health doesn't work very well.
Linda Chapman commented
I would go even further, that I have 3 customers that their required firewalls do not allow *.anything, they can only enter full URLs or IPs. Not all products support wildcards.
Neil G. commented
Note: There is a weekly update of azure public IP addresses https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653
Why doesn't that include the urls similar to how Office 365 documents their URL+IP address http://go.microsoft.com/fwlink/?LinkId=533185
John James commented
I am seeing the same issue on portal.azure.com from behind the corporate firewall.
HUMBERTO DEL CASTILLO commented
It is a firewall issue, I used fiddler to find out which one of the calls was failing and I found that the following call was being blocked at our firewall:
They made the change in the firewall and it works now.
I think if microsoft is using cross-site scripting at the azure portal they should publish the list of domains that have to be opened at the firewall in order to make it work.
HUMBERTO DEL CASTILLO commented
It happens to me and I don't think it is the firewall, it is intermittent.
I opened support ticket (#115111113363550) and they mentioned some outages could be the cause, but this is very annoying and a show stopper, specially for features like the resource groups that are only available at the new portal and not at the old one.
Rune Petersen commented
When signing on to portal.azure.com from our corporate network/PC's we keep getting a notification that : "Some subscriptions couldn't be retrieved. Try again later..". This is followed by a notification that our session has expired. (Attached screenshots).
We have no problem logging on to the old portal.
Can this be a network/firewall issue?
Eric Swanson commented
Sign-in: I constantly get the "to protect your privacy please sign-in again" message. Maybe because of firewall?
Matt Allison commented
The prior Azure portal had relatively few URLs (I think all manage.windowsazure.com actually) for the underlying .js and other components of the site.
The new portal pulls content from seemingly everywhere - each blade/component using different URLs including content from CDNs.
This broad array of sources does not work in our environment (proxy/firewall/policy issues) and the result is that the portal is completely unstable and can't be relied on for anything.
The request is to ensure that all components used by the new portal are under a consistent URL scheme and IP address range.