Red: Problemas de conectividad a Internet tras actualización del sistema operativo en máquina virtual Linux — Diagnóstico y pasos a seguir

I ran a troubleshoot again and this is the output:

La subred snet-ineos-prod-uksouth-f5ext-01 no tiene configurado un mecanismo de salida a Internet. En esa subred solo hay NICs privadas (nic-ineos-prod-uksouth-F5ext-01 y nic-ineos-prod-uksouth-F5ext-02) con IPs 10.144.3.4 y 10.144.3.5, sin IP pública asociada. Tampoco tiene asociada una tabla de rutas, NAT Gateway ni NSG. El balanceador externo de F5 tiene disableOutboundSnat=true, por lo que no proporciona SNAT de salida para las instancias backend. La ruta 0.0.0.0/0 hacia el appliance 10.144.1.132 existe, pero está asociada a otra subred (snet-ineos-prod-uksouth-svcfrt-01), no a snet-ineos-prod-uksouth-f5ext-01. No hay indicios de un incidente reciente de la plataforma que explique el problema. En conjunto, la causa es la ausencia de egreso configurado para esa subred, lo que deja a las VMs sin salida explícita a Internet.

So its mandatory to have a public IP to go out, there is no default snat? I thought that public IP is for accessing systems inside azure.

Hello @NTT-6055

Thank you for the details.

To clarify, it is not mandatory to assign a public IP directly to the VM for outbound Internet connectivity.

Azure supports several explicit outbound connectivity methods, such as:

• Azure NAT Gateway
• A public IP assigned to the VM
• Azure Load Balancer outbound rules
• A network appliance/firewall configured to provide Internet egress and SNAT

Regarding default outbound access, for new virtual networks created after March 31, 2026, Azure uses private subnets by default and an explicit outbound connectivity method is required.

Based on the current configuration, DNS resolution is working, but we do not see an explicit outbound mechanism for the affected subnet. This can explain why the VM resolves callhome.f5.com but cannot establish the outbound connection.

Since this connectivity was previously working, we would also recommend validating the VM's effective route for 0.0.0.0/0 and confirming what outbound path/SNAT mechanism was being used before the issue started. This will help us confirm the exact cause before making any configuration changes.

Likely cause: your VM/subnet currently has DNS resolution but no explicit outbound egress path (SNAT), so name resolution works but outbound TCP/HTTPS connections fail.

From your diagnostics, the key signals are:

• subnet without NAT Gateway / outbound rule / effective egress path,
• disableOutboundSnat=true on the external Load Balancer,
• default route not associated to the affected subnet.

1. Confirm effective outbound method for the exact subnet of the failing NICs.
   • Check if the subnet has one of these explicit outbound options:
     • NAT Gateway,
     • Standard Load Balancer outbound rules,
     • instance-level Public IP (if acceptable),
     • UDR to NVA/firewall that provides SNAT.
   • Reference: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access
2. If using private subnet design, configure explicit egress.
   • Recommended: associate a NAT Gateway to the failing subnet.
   • Reference: https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview
3. If using Standard Load Balancer for egress, verify outbound rules.
   • Ensure backend pool membership and outbound rule/protocol/SNAT allocation are correct.
   • Reference: https://learn.microsoft.com/en-us/azure/load-balancer/outbound-rules
4. Recheck UDR/next hop and NSG on the same subnet.
   • Confirm 0.0.0.0/0 effective route applies to the impacted subnet (not another subnet).
   • Confirm NSG allows required outbound traffic (for example TCP/443).
5. Validate after change.
   • curl -v https://callhome.f5.com
   • curl -v https://www.microsoft.com
   • Verify effective routes and NSG flow behavior for the affected NIC.

Important note on your question:

• A Public IP on each VM is not always mandatory.
• But you do need some explicit outbound method (NAT Gateway / LB outbound rule / NVA+SNAT / ILPIP).
• For newer/private subnet patterns, implicit default outbound isn’t something to rely on.

Risk/rollback:

• Egress changes can affect allow-lists and source IP seen by external services.
• If production-sensitive, apply to one VM/subnet first, validate, then roll out.

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”