Microsoft has always provided internet access by default for virtual machines. They do so by NATing that traffic with a Microsoft managed IP address if you don’t provide your own IP. You can use your own IP address by the following methods:
- Assign a public IP to the virtual machine or a load balancer/application gateway where that virtual machine is part of the backend pool.
- Assign a NAT gateway to the subnet that the virtual machine lives within.
- Setup a route table that has a custom route for 0.0.0.0/0 where it is sent to a firewall appliance in the cloud or forced tunneled back on-premise through the VPN or ExpressRoute connection.
- Have virtual networks connected to a vWAN Hub that is secured with a FW and have routes propagated to route internet traffic through the firewall.
Microsoft is making a change on September 30, 2025 where default access will no longer be allowed. What that means, is that unless you fit one of the above criteria, your virtual machines will lose internet access. This will impact anything on the VM that needs to connect to the internet like security/monitoring agents, patching of the systems, connections to internet sources for the running applications to function, etc.
Microsoft has a good article that talks about this behavior and the different options: Default outbound access in Azure - Azure Virtual Network | Microsoft Learn
As you look to implement one of the three above options, a public IP assigned directly to a virtual machine should be used only when necessary as it is the most insecure method available. If you are assigning a public IP to a virtual machine, load balancer, application gateway, etc. it is your responsibility to ensure you have the appropriate security controls in place to protect that virtual machine.
Virtual networks are getting a new capability that as of this writing is currently in preview, where you can make a subnet private. By making a subnet private, you are basically disabling this default outbound access before September 30, 2025. Virtual machines will still have outbound connecting if the meet the above criteria.
Determining if you have virtual machines in your environment that might be impacted by this change can be challenging if they are spread out over multiple environments, subscriptions and virtual networks. Below is a resource graph query that you can use to help see if you have any virtual machines that would be impacted to help you prepare for this change by Microsoft.
Graph query that shows Virtual Machines that do not have a public IP or in a subnet that has a NAT gateway or route table that sets the route for 0.0.0.0/0; if the VM contains more than one NIC it may show up in the results even if it is not impacted.
---
Resources // gets VMs that are assigned to those nics
| where type == 'microsoft.compute/virtualmachines'
| extend nicId = tolower(tostring(properties.networkProfile.networkInterfaces[0].id))
| join kind = inner (
Resources // gets nics that live in subnets that don't meet outbound connectivity criteria
| where type == 'microsoft.network/networkinterfaces'
| extend subnetId = tolower(tostring(properties.ipConfigurations[0].properties.subnet.id))
| join kind = inner (
Resources // gets subnets that do not have a NAT gateway, route table or custom route for 0.0.0.0/0
| where type == 'microsoft.network/virtualnetworks'
| extend subnets = properties.subnets
| mv-expand subnets
| extend routeTableId = tolower(tostring(subnets.properties.routeTable.id))
| extend natGatewayId = tolower(tostring(subnets.properties.natGateway.id))
| extend subnetId = tolower(tostring(subnets.id))
| join kind = leftouter (
Resources // gets route tables that have a custom route for 0.0.0.0/0
| where type == 'microsoft.network/routetables'
| where properties.routes has '0.0.0.0/0'
| extend routeTableId = tolower(id)
) on routeTableId
| project name, subnets.name, subnets.properties.addressPrefix, location, resourceGroup, subscriptionId, subnetId, routeTableId, routeTableId1, natGatewayId
| where isempty(routeTableId) or (isnotempty(routeTableId) and isempty(routeTableId1)) // only shows subnets that do not have a route table assigned or a route table that does not have a 0.0.0.0/0 route
| where isempty(natGatewayId) // only shows subnets that do not have NAT gateways assigned
) on subnetId
| extend nicId = tolower(id)
| extend publicIPId = tostring(properties.ipConfigurations[0].properties.publicIPAddress.id)
| extend hasPublicIP = iif(isempty(publicIPId), false, true)
) on nicId
| where hasPublicIP == 0 // only shows VMs that do not have public IPs assigned
---
If you have virtual machines show up as results in this query, you should review them to see if they are part of virtual networks that are connected to a secured vWAN hub that protects internet bound traffic. You can do this by looking at the effective routes on the Nic and ensuring the 0.0.0.0/0 route is being sent to an internal IP address: Diagnose an Azure virtual machine routing problem | Microsoft Learn
If you would like assistance in building a plan for remediation or to increase security, please contact us as we can customize a solution that meets your needs.
