This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 6%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERM%3C/text%3E%3C/svg%3E)
I'm configuring a new Azure Relay service, wcfrelay, for an onpremise data gateway. I want to use IP address white listing as described here. The goal is to allow powerbi to connect to onprem SQL servers.
I added public network CIDR to allow my onprem server. But now I'm seeing a public IP address from Azure being blocked. The data gateway status in powerplatform admin also shows as disconnected. The relay I setup diagnostics for the Relay and seeing Deny connection in the Log Analytics for 20.92.128.xx
I also have enabled Allow Microsoft Trusted services to Bypass the firewall. Could it be some other service that's not on the trusted list? Is there a way I can determine what service it is.
I'm concerned about the security implications of whitelisting an Azure IP address or broad ranges.
Is this expected behaviour?
An Azure service that provides cloud messaging as a service and hybrid integration.
I should add, if I don't use an IP filtering, or it I add the Azure public IP that is being blocked, it all works fine.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(41.6, 65%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPK%3C/text%3E%3C/svg%3E)
Hi @Robin Martin ,
This query is outside the scope of this Q&A forum. For power-bi related issues, please raise your concern in the dedicated forum linked below.
https://community.fabric.microsoft.com/t5/Power-BI-forums/ct-p/powerbi
Answer accepted by question author
The 20.x deny is just the relay hitting its alt mgmt‑path… it shifts pools when your tenant’s region/perms don’t line up with the data‑plane, so the fw treats it like outside traffic. u just allow the single hop from the diag logs. I think it’s stable fix when the backend drifts like this.
Hi kagiyama, thanks I appreciate the response. It sounds like adding a single /27 CIDR is the answer and a minimal security risk.
The other option we'll consider is using the automatic Relay creation rather than the specify our own Relay details. Since our tenant's resources are all in the same region.
When configuring IP firewall rules for Azure Relay, it's important to ensure that all necessary IP addresses are whitelisted to avoid blocking legitimate services. Since you have already added your on-premises server's public network CIDR and enabled the option to allow Microsoft Trusted services to bypass the firewall, the blocking of the Azure public IP (20.92.128.xx) could be due to a service that is not included in the trusted list.
To determine which service is attempting to connect and being blocked, you can check the logs in Log Analytics for more detailed information about the connection attempts and the specific services involved. This will help identify if there are additional Azure services that need to be included in your firewall rules.
Regarding security implications, whitelisting broad ranges or specific Azure IP addresses can pose risks, as it may inadvertently allow unwanted access. It's advisable to limit the ranges as much as possible and regularly review the logs to monitor for any unauthorized access attempts.
This behavior of blocking connections from Azure IPs is expected if those IPs are not explicitly allowed in your firewall rules, even with the trusted services option enabled.
References: