When deploying Azure Migrate Appliances to discovery servers, the appliance needs outbound internet access. In many IT environments, servers are disallowed internet access unless prescribed to certain URL sets. Gratefully Microsoft have given us a list of what they think is the list of URLs that the appliance will need to have whitelisted. This can be found here:
https://docs.microsoft.com/en-us/azure/migrate/migrate-appliance#public-cloud-urls
Issue
Once the appliance has booted up and your onto the GUI, you must ener your Azure Migrate Project key from your subscription and then authenticate to your subscription. We entailed the following error when attempting to resolve the initial key:
Azure Migrate Error
Failed to connect to the Azure Migrate project. Check the errors details, follow the remediation steps and click on ‘Retry’ button
The Azure Migrate Key doesn’t have an expiration on it so this wasn’t the issue. We had whitelisted the URL‘s but on the firewall we were seeing dropped packets:
| 13:40:41 | Default DROP | TCP | 10.0.0.10 | : | 50860 | → | 204.79.197.219 | : | 443 | |
| 13:40:41 | Default DROP | TCP | 10.0.0.10 | : | 50861 | → | 204.79.197.219 | : | 80 | |
| 13:40:41 | Default DROP | TCP | 10.0.0.10 | : | 50857 | → | 152.199.39.242 | : | 443 | |
| 13:40:42 | Default DROP | TCP | 10.0.0.10 | : | 50862 | → | 204.79.197.219 | : | 80 | |
| 13:40:42 | Default DROP | TCP | 10.0.0.10 | : | 50858 | → | 104.74.50.201 | : | 80 | |
| 13:40:43 | Default DROP | TCP | 10.0.0.10 | : | 50863 | → | 52.152.110.14 | : | 443 | |
| 13:40:44 | Default DROP | TCP | 10.0.0.10 | : | 50860 | → | 204.79.197.219 | : | 443 | |
| 13:40:44 | Default DROP | TCP | 10.0.0.10 | : | 50861 | → | 204.79.197.219 | : | 80 | |
| 13:40:45 | Default DROP | TCP | 10.0.0.10 | : | 50862 | → | 204.79.197.219 | : | 80 | |
| 13:40:46 | Default DROP | TCP | 10.0.0.10 | : | 50863 | → | 52.152.110.14 | : | 443 | |
| 13:40:46 | Default DROP | TCP | 10.0.0.10 | : | 50859 | → | 204.79.197.219 | : | 443 | |
| 13:40:47 | Default DROP | TCP | 10.0.0.10 | : | 50864 | → | 40.90.189.152 | : | 443 | |
| 13:40:47 | Default DROP | TCP | 10.0.0.10 | : | 50865 | → | 52.114.36.3 | : | 443 | |
| 13:40:49 | Default DROP | TCP | 10.0.0.10 | : | 50864 | → | 40.90.189.152 | : | 443 | |
| 13:40:50 | Default DROP | TCP | 10.0.0.10 | : | 50865 | → | 52.114.36.3 | : | 443 | |
| 13:40:50 | Default DROP | TCP | 10.0.0.10 | : | 50860 | → | 204.79.197.219 | : | 443 | |
| 13:40:50 | Default DROP | TCP | 10.0.0.10 | : | 50861 | → | 204.79.197.219 | : | 80 | |
| 13:40:51 | Default DROP | TCP | 10.0.0.10 | : | 50862 | → | 204.79.197.219 | : | 80 | |
| 13:40:52 | Default DROP | TCP | 10.0.0.10 | : | 50863 | → | 52.152.110.14 | : | 443 |
Reviewing the SSL certificates on these IP addresses, they are all Microsoft services with multiple SAN entries. We also had a look at the traffic from the developer tools in the browser:
We can see that the browser is trying to start a AAD workflow for device login, which is articulated in the onboarding documentation. Our issue was that the JavaScript for inside the browser session wasn’t located in the whitelist URLs. Reviewing the SAN entries in the certificates presented in the IP destination table we looked for ‘CDN’ or ‘Edge’ URLs.
The fix
The following URLs were added to the whitelist group for the appliance and problems went away.
| 204.79.197.219 | *.azureedge.net |
| 152.199.39.242 | *.azureedge.net |
| 152.199.39.242 | *.wpc.azureedge.net |
| 152.199.39.242 | *.wac.azureedge.net |
| 152.199.39.242 | *.adn.azureedge.net |
| 152.199.39.242 | *.fms.azureedge.net |
| 152.199.39.242 | *.azureedge-test.net |
| 152.199.39.242 | *.ec.azureedge.net |
| 152.199.39.242 | *.wpc.ec.azureedge.net |
| 152.199.39.242 | *.wac.ec.azureedge.net |
| 152.199.39.242 | *.adn.ec.azureedge.net |
| 152.199.39.242 | *.fms.ec.azureedge.net |
| 152.199.39.242 | *.aspnetcdn.com |
| 152.199.39.242 | *.azurecomcdn.net |
| 152.199.39.242 | cdnads.msads.net |
