We received many requests regarding the IP addresses used by production environments of Dynamics 365 for Finance and Operations in the cloud. There might be multiple reasons for those requests: configure services and devices, allow access from the company’s network or simply monitor the availability. This blog is written to demystify some wrong assumptions.

Can I rely on a static IP address?

The short answer is: no. Due the nature of the cloud deployment, there is no guarantee of a static or reserved IP address for the production environment in Dynamics 365 for Finance and Operations.
The IP address of the production environment refers to the Azure Traffic Manager sitting on top of the infrastructure and responsible for the correct routing in the High Availability architecture behind the scenes. Therefore, there might be many reasons for the IP addresses to change over time (environment redeployment, failover, rollbacks, upgrades, etc..) including architectural modifications in the Azure landscape. Nevertheless, most of the time you won’t notice the IP address change.

It doesn’t sound fair!

Well, the actual point is: why do you need the IP address? The most common answers are: to configure an inbound port on the firewall exposing an on-premises service to Dynamics 365 for Finance and Operations, or to limit users navigation to a controlled subset of websites.

In the first case you may really need the IP address, but you should also consider other solutions. For example, in an asynchronous integration scenario, you may use a combination of Logic Apps and on-premises gateways to interact with local applications. In synchronous scenarios you may extend your legacy application through the cloud using Azure Service Bus and WCF Relay service securely exposing Windows Communication Foundation services that reside within the corporate enterprise network to the public cloud, without having to open a firewall connection, or requiring intrusive changes to a corporate network infrastructure.

Note : There is also a static list of IPs for outgoing IP addresses for Logic Apps and Connectors per Region, you can see more detail here. Also, if you need a single IP or if you want to avoid other users with a Logic App in the same region access to your resources, you can use Azure API Management to act as reverse proxy for the Logic App.

For the second scenario, limiting users’ navigation, you can leverage the layer 7 capabilities most of the modern firewall and proxy devices have. These tools can scan the header of the packages and apply rules based on the URI instead of the IP address.
In any case, you should generally avoid this approach because some static content (icons, graphical elements)  of the ERP website may temporary reside on a Content Delivery Network (CDN) and therefore be fetched from a different URI or IP address.

Note: Layer 7 packet analysis should be carefully tested because it may introduce some latency in the communication path.

Ok but I still want the IP addresses.

Ok don’t worry. There are essentially two ways to approach it.

1. Whitelist all the IP addresses related to the Azure Region where your environment is located.
   You can download an XML file with the subnets list from the official Microsoft Azure Datacenter IP Ranges An updated file is posted on a weekly basis, typically on Tuesday. It reflects the currently deployed ranges and any upcoming changes to the IP ranges. New ranges appearing in the file will not be used in the datacenters for at least one week.

   Note: you can also use the direct link for automation needs (https://download.microsoft.com/download/0/1/8/018E208D-54F8-44CD-AA26-CD7BC9524A8C/PublicIPs_20180508.xml), replacing the file name suffix with the current date in yyyymmdd format.

2. Actively monitor the IP address of your environment using a DNS request. This task can be quickly archived using local resources and a little bit of scripting but a system administrator may easily automate it leveraging Microsoft Flow to create a simple notification system (The license is included up to 15K user’s executions/month, see the Licensing Guide for more information).
   Here’s an example how you can create the flow in 5 minutes.
   • Create a new Flow with a recurrence trigger (e.g. 30 minutes) and call a web service to get the current public IP address (in this example we are using a public API from dns-api.org). Complete the step parsing the JSON response.
     
   • Loop the response to find the A record and compare with the current IP address. If it’s different than expected, notify the owner (alternatively send an email to the IT team).
     

You can even export this simple Flow to create Logic App in your subscription and perform more complex and automated tasks in your on-premises or cloud solutions (e.g. modify values in SQL tables, change values in local files, embed the notification in your on-premises monitoring system etc..).

/* DISCLAIMER:
Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose.

This post assumes that you are familiar with the programming language that is being demonstrated and the tools that are used to create and debug procedures. */