Dynamics 365 Business Central: using a static IP address to access APIs.

Sometimes in Dynamics 365 Business Central projects you can have very strict security requirements for integrations with third-party systems. One of the quite common integration scenario you can have is that the third-party system strictly requires a static IP address for all the incoming traffic. In simple words:

• The third-party system sends a call to a Dynamics 365 Business Central API.
• The API response need to come from a static IP address, granted in firewall rules.

As you can imagine, this scenario is not possible on a SaaS environment because the IP addresses of a Dynamics 365 Business Central tenant are not fixed. To support setting up a firewall rule for this type of security requirement, you need to support Azure Service Tags. I wrote in the past a post here that I recommend to check.

This is the recommended approach to follow, but unfortunately not all third-party systems are able to support Azure Service Tags.

What can you do in such cases?

A possible solution is to use an Azure Function as a middle layer between the third-party system and Dynamics 365 Business Central. All the API requests coming from the third-party systems are routed to the Azure Function, that in turns calls the Dynamics 365 Business Central APIs (simple routing). Then the response of the Dynamics 365 Business Central API will be routed to the third-party systems via the Azure Function. This Azure Function must have a static IP address and you can control Azure Functions outbound IP with an Azure virtual network NAT gateway. The Azure Function must be deployed in the Premium Plan or in the new Flex plan to be able to support this scenario.

Virtual network address translation (NAT) simplifies outbound-only internet connectivity for virtual networks. When configured on a subnet, all outbound connectivity uses your specified static public IP addresses. A NAT can be useful for apps that need to consume a third-party service that uses an allowlist of IP address as a security measure.

A diagram representing the solution is the following:

How to control Azure Functions outbound IP with an Azure virtual network NAT gateway.

To support this scenario, the first step you need to do is to create a virtual network in your Azure Portal and a corresponding subnet:

Then you need to create an Azure Function app in the Premium or in the Flex plan (here I’ve used the Premium plan):

The Azure Function must be deployed in the same Azure Region as your virtual network.

The, in the Function app go to Settings and click on Networking. Here you need to click on the Virtual Network Integration option to configure a VNET integration:

Then click on Add Virtual network integration:

Select the Virtual Network previously configured and the relative subnet and click Connect:

In the newly created Virtual Network integration configuration, check that Outbound Internet Traffic is selected:

Now go to your Azure Function app, select the Environment Variables menu and here create a new environment variable called WEBSITE_VNET_ROUTE_ALL with the value of 1.

As per Microsoft documentation, this setting indicates whether all outbound traffic from the app is routed through the virtual network. A setting value of 1 indicates that all application traffic is routed through the virtual network:

Now always from the Azure Portal, create a public IP address (create it in the same Azure Region as your VNET):

Then you need to create the NAT gateway. From the Azure Portal, search for NAT gateways and create a new gateway as follows:

Then in the Outbound IP pane, assign the public IP previously created:

and in the Subnet pane, assign to the NAT gateway the Virtual Network and its related subnet:

Check the Outbound IP setting of your NAT gateway and you should see its associated public IP address:

Now you’re ready to go…

For this post, I’ve simply created an HTTP trigger function that simply performs a GET operation to the https://ifconfig.me url (just to retrieve the rough response of this API in order to check the outbound request IP address):

When sending the GET request to the Azure Function, you can see that now the outbound request is coming from my static IP address:

The returned IP address matches the public IP address of the NAT gateway, confirming that the Azure function has been configured with a NAT gateway and that all traffic now flows through the NAT gateway using the assigned public IP address and egress IP address.

In this way, in the Azure Function call you can route the incoming request to the Business Central API, then read the response and return this response from the static IP address.

Original Post https://demiliani.com/2025/06/03/dynamics-365-business-central-using-a-static-ip-address-to-access-apis/