Overview
This article describes the network traffic flows involved in private networking for a Turbo360 private hosted instance. It covers each component's inbound and outbound paths, the protocols and ports used, and the role of private endpoints and VNet integration in keeping traffic within your virtual network.
Business value
Understanding traffic flows lets you design your subnet topology correctly, configure DNS and firewall rules without guesswork, and troubleshoot connectivity failures with confidence. This article is required reading before configuring private networking.
How it works
Every Turbo360 component — web app, function apps, SQL database, storage account, and monitoring — has a defined inbound path (via private endpoints or private link) and an outbound path (via VNet integration or direct private endpoint access). The sections below describe each component's traffic flows in detail.
Turbo360 web application view
End user inbound to Turbo360 web application
Client (e.g., a user in your organization on the network) → VNet → Private endpoint of web app → web application serving Turbo360.
The public*.azurewebsites.netaddress is typically blocked; DNS for the app hostname resolves to the private endpoint's private IP.
Turbo360 web application → Azure SQL
App (via VNet Integration subnet) → Private DNS resolves
*.database.windows.netto SQL private endpoint → SQLSQL firewall is restricted to the private endpoint; public network access is off.
Turbo360 web application → Storage (code/content)
At cold start or deployment, the app fetches the ZIP package from Blob storage via the storage private endpoint (using
WEBSITE_RUN_FROM_PACKAGE).Any runtime asset access (e.g., blobs) follows the same private path.
Turbo360 web application → Telemetry ingestion
App → App Insights private link endpoint for telemetry.
Agent/SDK or diagnostics → Log Analytics Workspace private link endpoints for logs and metrics. This keeps monitoring ingestion off the public internet.
Turbo360 web application → Azure Management API
App (via VNet Integration subnet) → Virtual Network → Azure
DNS resolved from VNet DNS.
Routes to a public address at Microsoft.
Turbo360 web application → Kovai
Used for license activation.
App (via VNet Integration subnet) → Virtual Network → Kovai
DNS resolved from VNet DNS.
Routes to a public address at Kovai on Microsoft Azure.
Other optional configurations
The following traffic flows apply depending on which notification and integration features you use. All route through the App Service outbound VNet integration, covering both the web app and function apps.
Turbo360 web application → Your SMTP server
Turbo360 web application → ServiceNow
Turbo360 web application → Teams
Turbo360 web application → Twilio
Turbo360 web application → PagerDuty
Turbo360 web application → Jira
Turbo360 web application → Notification channels
Turbo360 function apps view
The traffic flows for function apps are identical to those for the Turbo360 web application, with one exception: end-user inbound traffic to the web application does not apply to function apps. An equivalent flow would occur if an Azure administrator accessed a function app directly through the Azure portal.
SQL database view
The database is connected to the virtual network via a private endpoint on a dedicated subnet.
Public network access is turned off on the database.
App Insights / Log Analytics view
App Insights and the Log Analytics Workspace have private link enabled.
They are not accessible from outside the network.
Deployment machine view
The Turbo360 private hosted instance is deployed using a virtual machine. The deployment machine is connected to the virtual network and accesses resources via private endpoints:
Deployment machine → VNet → Private endpoint for web apps and function apps
Port 443 for deployment.Deployment machine → VNet → Private endpoint for SQL
Port 1433 for SQL migrations.Deployment machine → VNet → Private endpoint for storage
Port 443 for code package deployment.