Forum Discussion
Fabric Virtual network data gateways - offline
We have setup a Virtual network data gateway to connect to some Azure resources. This worked fine; we can connect to sql server in Azure, or to a Storage Account.
But after some time, the Virtual network data gateway goes offline, and all connections that depend on it fail !?
I saw an earlier post, where the solution answer was 'technicians are looking into it'!?
Anyone know how to keep this gateway online?
Hi h_l_de_boer,
Besides the known certificate issue already linked, it's worth ruling out that the gateway is simply asleep. That is by design, and it is the most common reason a VNet data gateway "works for a while, then shows offline".
A VNet data gateway is a managed container that is deallocated after a period with no queries. In the UI that shows up as offline/inactive. It starts again on the next request, but that cold start can take a few minutes, and a refresh or a test connection that arrives in that window can fail.
Manage connections and gateways -> Virtual network data gateways -> select the gateway -> Settings -> "Inactivity time before sleep" (default is short) -> raise it to cover the gap between your scheduled refreshesIf raising that doesn't explain it, these are the other things I would check, in order:
capacity -> F SKU paused / scaled down overnight? gateway goes with it (common when the capacity is paused by automation to save cost) subnet -> delegated to Microsoft.PowerPlatform/vnetaccessLinks, enough free IPs for the number of gateway members DNS / NSG -> private endpoints resolve from that VNet; no NSG / route table change blocking outbound certificate -> private CA SQL cert (known issue above)A practical workaround while testing: schedule a lightweight refresh, or a pipeline Lookup on a tiny query, just before the main refresh window. The gateway is then already warm when the real load starts.
So my overall approach would be:
check gateway status right before a failure -> asleep vs truly down asleep -> raise inactivity time before sleep / warm it up first down -> capacity paused? subnet IPs / delegation? DNS + NSG? cert -> register root CA (known issue mitigation)AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
4 Replies
- tayloramy
Super User
Hi h_l_de_boer,
This is an active issue:
Preferred mitigation - register the Root CA:
If the SQL Server certificate was issued by a private certificate authority, register the issuing public Root CA certificate in the VNet data gateway's Certificate & proxy support settings. This allows certificate validation to succeed while preserving encrypted SQL connectivity. Retry the test connection after the certificate is registered.
Temporary workaround - skip validation:
When creating the SQL Server connection, select Skip test connection. The connection can then be created and refreshes can succeed. The connection might continue to display as Offline, so confirm successful operation by running and monitoring a refresh.
jubinsoniContinued Contributor
Hi h_l_de_boer,
Besides the known certificate issue already linked, it's worth ruling out that the gateway is simply asleep. That is by design, and it is the most common reason a VNet data gateway "works for a while, then shows offline".
A VNet data gateway is a managed container that is deallocated after a period with no queries. In the UI that shows up as offline/inactive. It starts again on the next request, but that cold start can take a few minutes, and a refresh or a test connection that arrives in that window can fail.
Manage connections and gateways -> Virtual network data gateways -> select the gateway -> Settings -> "Inactivity time before sleep" (default is short) -> raise it to cover the gap between your scheduled refreshesIf raising that doesn't explain it, these are the other things I would check, in order:
capacity -> F SKU paused / scaled down overnight? gateway goes with it (common when the capacity is paused by automation to save cost) subnet -> delegated to Microsoft.PowerPlatform/vnetaccessLinks, enough free IPs for the number of gateway members DNS / NSG -> private endpoints resolve from that VNet; no NSG / route table change blocking outbound certificate -> private CA SQL cert (known issue above)A practical workaround while testing: schedule a lightweight refresh, or a pipeline Lookup on a tiny query, just before the main refresh window. The gateway is then already warm when the real load starts.
So my overall approach would be:
check gateway status right before a failure -> asleep vs truly down asleep -> raise inactivity time before sleep / warm it up first down -> capacity paused? subnet IPs / delegation? DNS + NSG? cert -> register root CA (known issue mitigation)AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
jubinsoni, thank you for quick response.
On the "starts again on the next request, but that cold start can take a few minutes" -part; I am not shure that worked for us... I will have to test this.
Meanwhile, we set the keep-alive to 24 hours and will, as you suggested, put an automatic refresh in place to keep it going!
Murtaza_Ghafoorh_l_de_boer
This is not usual behaviour, most probably the firewall rules in your domain or network settings issue, the better approach is to diagnose this step by step.Propose Solution:
- Check the gateway's auto-shutdown settings.
- Verify VNet connectivity, DNS, and network security rules.
- Review gateway diagnostic logs to identify the root cause.
- Check Microsoft Fabric's known issues for any related service incidents.
(https://support.fabric.microsoft.com/known-issues/
)
If this helps, ✓ Mark as Kudos | Help Other
