Network configuration

Overview

This article describes the network configuration options available for a Turbo360 private hosting deployment. It covers outbound VNET integration, inbound private endpoints, DNS configuration, and post-deployment network hardening. Network configuration can be applied during deployment using the installer wizard or added to an existing deployment afterwards.

Business value

Applying network controls to your Turbo360 private instance restricts access to your Azure virtual network, removes public endpoints from SQL and Storage, and routes application traffic through your own network perimeter. This supports data residency requirements, compliance policies, and defence-in-depth security postures without requiring a separate proxy or gateway layer.

Prerequisites

• A completed Turbo360 private deployment (see Deployment)
• An Azure Virtual Network in the same region as the Turbo360 resource group
• A subnet delegated to Microsoft.Web/serverFarms for App Service VNET integration
• A Premium tier App Service Plan (Standard tier does not support VNET integration)
• Contributor access to the resource group and network resources

Required permissions

How it works

Turbo360 private hosting supports four network controls that can be applied independently or in combination:

• Outbound VNET integration — routes outbound traffic from the Web App and Function Apps through your VNET subnet. Required before private endpoints on SQL and Storage are reachable from the application.
• Inbound private endpoints (App Service) — removes public inbound access to the Web App and Function Apps. Access is restricted to resources within the VNET.
• Private endpoint for SQL — restricts the SQL database to your VNET. Public network access to SQL is disabled.
• Private endpoint for Storage — restricts the Storage Account to your VNET. Public network access to Storage is disabled.

All four controls are independent. You can apply outbound VNET integration without creating private endpoints, or create private endpoints without enabling inbound restrictions on the App Service.

Configuration

Option 1 — Configure network controls during deployment

The Turbo360 installer wizard includes an Include VNet configuration option. When enabled:

1. The installer creates outbound VNET integration for all Function Apps and the Web App.
2. SQL and Storage are placed inside the VNET.
3. Public network access to SQL and Storage is disabled automatically after post-deployment verification completes.

This is the recommended approach when you want full network isolation from day one. See VNet configuration during deployment for the step-by-step walkthrough.

Option 2 — Configure network controls after deployment

Because every customer's network setup is different, you may prefer to deploy the application first and layer on network controls afterwards. Turbo360 will assist with post-deployment VNET configuration.

Contact Turbo360 support to initiate post-deployment network configuration. The typical sequence is:

1. Enable outbound VNET integration on the Web App and Function Apps.
2. Create a private endpoint for the SQL database and disable public access.
3. Create a private endpoint for the Storage Account and disable public access.
4. Optionally, create inbound private endpoints for the Web App and Function Apps to remove public inbound access.
5. Configure Private DNS Zones for each private endpoint.

DNS configuration

Private endpoints require Private DNS Zone entries so that application components resolve resource hostnames to private IP addresses rather than public endpoints.

Each zone must be linked to the VNET that contains the Turbo360 resources. If your organisation uses custom DNS resolvers or hub-spoke network topology, ensure conditional forwarders route these zones to Azure DNS (168.63.129.16).

Port and firewall requirements

The following ports must be open for Turbo360 components to communicate:

See Ports for the full port reference.

Example scenario

A platform engineer has completed a Turbo360 deployment and now needs to satisfy a security review requiring that SQL and Storage are not publicly accessible. They enable outbound VNET integration on the Web App and all three Function Apps, create private endpoints for SQL and Storage in the Turbo360 subnet, disable public access on both resources, configure Private DNS Zones for privatelink.database.windows.net and privatelink.blob.core.windows.net, and link both zones to the VNET. The security review confirms no public endpoints remain on data-tier resources.

Limitations

• VNET integration requires a Premium tier App Service Plan. Standard tier does not support private endpoint reachability from App Service outbound traffic.
• Inbound private endpoints on the Web App remove public access for all users. Ensure VPN or ExpressRoute connectivity exists for users before enabling inbound restrictions.
• Post-deployment VNET configuration requires assistance from Turbo360 support. Self-service post-deployment network configuration is not available through the Turbo360 portal.
• Private DNS Zone configuration must be completed before private endpoints are functional. Misconfigured DNS results in connectivity failures that surface as timeout errors in the application.
• Only the Azure environments listed in the Deployment article are supported (Global Cloud, China Cloud, US Government). Network configuration steps and resource names may differ slightly between environments.

Troubleshooting

1. Application cannot connect to SQL after private endpoint is created
   Cause: Private DNS Zone for privatelink.database.windows.net is not linked to the VNET, or the zone record is missing.
   Fix: Open the Private DNS Zone in the Azure portal, verify the A record for the SQL server exists, and confirm the zone is linked to the correct VNET. If using a custom DNS resolver, add a conditional forwarder to 168.63.129.16.

2. Function App cannot reach Storage after VNET integration is enabled
   Cause: VNET integration is enabled but a private endpoint for Storage has not been created, or DNS resolution for Storage is still resolving to the public endpoint.
   Fix: Create a private endpoint for the Storage Account and configure the privatelink.blob.core.windows.net DNS Zone. Restart the Function Apps after DNS propagation completes.

3. Users cannot access the Turbo360 portal after inbound private endpoint is applied
   Cause: Inbound private endpoint removed public access before VPN or ExpressRoute connectivity was in place for users.
   Fix: Verify that users have network access to the VNET via VPN gateway or ExpressRoute. If not, temporarily re-enable public access on the Web App while connectivity is established.

4. VNET integration option is greyed out in the Azure portal
   Cause: App Service Plan is at Standard tier, which does not support VNET integration.
   Fix: Scale the App Service Plan to Premium P1v3 or higher in the Azure portal, then return to the App Service networking settings to enable VNET integration.

5. Post-deployment network configuration request has not received a response from Turbo360
   Cause: Support ticket not yet assigned or additional information is required.
   Fix: Contact Turbo360 support with the resource group name, VNET resource ID, and subnet details. Reference the deployment date and instance URL to expedite the request.

FAQs

1. Can I configure VNET integration without creating private endpoints?
   Yes. Outbound VNET integration can be enabled independently. This routes outbound traffic through your VNET without restricting inbound access to the Web App or removing public access from SQL and Storage. You can add private endpoints at any time after outbound integration is in place.

2. Does Turbo360 support hub-spoke network topologies?
   Yes. VNET peering between spoke VNETs and a hub VNET is supported. Ensure Private DNS Zone links and conditional forwarder rules are configured at the hub level so that all spokes can resolve private endpoint hostnames correctly.

3. Is VNET integration required for the BAM push model?
   No, VNET integration is not required for BAM push model functionality. However, if your API Management instance or Logic Apps are inside a private VNET, you will need to ensure the Turbo360 BAM API endpoint is reachable from those resources.

Related articles

• Private hosting architecture
• VNet configuration during deployment
• Infrastructure requirements
• Private networking overview
• Ports