Debug VM Network Connectivity with Ubuntu on GPU Cloud (2026 Guide) banner image

Debug VM Network Connectivity with Ubuntu on GPU Cloud (2026 Guide)

When your Ubuntu VM can SSH but workloads fail on DNS resolution, package installs, or API callbacks, these read-only diagnostics generate a structured network report to identify the root cause.

Network Debug Ubuntu 24.04 DNS Firewall Egress
MCP Recipe Available

This guide exists as a tested, machine-readable recipe in the Massed Compute MCP. Skip the manual steps and let an AI agent handle the network diagnostics automatically. Learn more about MCP automation.

Network connectivity issues are among the most frustrating problems in cloud computing. Your VM responds to SSH, but Hugging Face downloads time out, pip installations fail, or API callbacks never reach their destination. This guide provides systematic read-only diagnostics to identify DNS, routing, egress HTTPS, and firewall issues without changing any configurations.

The diagnostics generate a structured report with clear sections for DNS resolution, egress connectivity, listening ports, and firewall snapshots. Unlike trial-and-error troubleshooting, this approach gives you the complete network picture before making any changes.

Technology Stack
Component Purpose Notes
Ubuntu 24.04 Base operating system LTS with modern networking stack
SSH diagnostics Remote network checks No package installs required
DNS resolution Name lookup testing Tests both system and custom resolvers
HTTPS egress Outbound connectivity Tests Hugging Face, PyPI, GitHub
UFW/netfilter Firewall snapshot Read-only rule inspection
System Requirements
Resource Minimum Recommended
vCPUs 2 cores 4+ cores
RAM 4 GB 8+ GB
Storage 20 GB 50+ GB
Network SSH access Public IP assigned
OS Ubuntu 24.04 Fresh installation

Massed Compute VM Pricing

Pricing data fetched July 15, 2026. No matching SKUs found for the minimum requirements. Check live pricing for current availability and rates.

Cost optimization: Use existing VMs for network diagnostics when possible. These read-only checks don’t require dedicated instances.

Step-by-Step Network Diagnostics

1

Verify VM Access

Confirm your VM is running and SSH-accessible before starting network diagnostics.

ssh -i ~/.ssh/your_key -p 22 ubuntu@YOUR_VM_IP 'echo "VM access confirmed"'

You should see “VM access confirmed” printed to confirm basic connectivity.

2

DNS Resolution Test

Test both system DNS and common public resolvers to identify DNS issues.

ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== DNS Resolution ===" && 
nslookup google.com && 
nslookup huggingface.co && 
dig @8.8.8.8 pypi.org && 
cat /etc/resolv.conf'

Look for failed lookups or timeout errors that indicate DNS problems.

3

Egress HTTPS Connectivity

Test outbound HTTPS connections to common package repositories and APIs.

ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Egress HTTPS ===" && 
curl -I --connect-timeout 10 https://huggingface.co && 
curl -I --connect-timeout 10 https://pypi.org && 
curl -I --connect-timeout 10 https://github.com && 
curl -I --connect-timeout 10 https://api.github.com'

Successful responses show HTTP/2 200 or similar status codes. Connection timeouts indicate egress blocking.

4

Network Interface Status

Check network interface configuration and routing table.

ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Network Interfaces ===" && 
ip addr show && 
echo "=== Routing Table ===" && 
ip route show && 
echo "=== Default Gateway ===" && 
ping -c 3 $(ip route | grep default | awk "{print \$3}")'

Verify your VM has a valid IP, default route, and can reach the gateway.

5

Listening Ports Audit

Document which services are listening on which ports.

ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Listening Ports ===" && 
ss -tlnp && 
echo "=== Process Network Usage ===" && 
netstat -tulnp | head -20'

This helps identify port conflicts or unexpected services.

6

Firewall Snapshot

Capture current firewall rules without requiring sudo access.

ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Firewall Status ===" && 
ufw status 2>/dev/null || echo "UFW status requires sudo" && 
echo "=== iptables (if accessible) ===" && 
iptables -L 2>/dev/null || echo "iptables requires sudo" && 
echo "VM_NETWORK_CONNECTIVITY_OK"'

The final token confirms the diagnostic completed successfully.

Troubleshooting Common Issues

DNS Resolution Failures

If nslookup or dig commands fail, check your /etc/resolv.conf file. Many cloud providers use their own DNS servers. Try switching to public DNS temporarily:

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

Egress HTTPS Blocked

If curl commands timeout or fail with connection errors, your cloud provider may have egress filtering. Check your security group rules and firewall policies. Some providers require explicit outbound rules for HTTPS traffic.

SSH Key Rejection

If SSH connections fail with “Permission denied (publickey)”, remove the old host key and verify your private key:

ssh-keygen -R YOUR_VM_IP
ssh-add ~/.ssh/your_key

Network Interface Down

If ip addr show shows your interface as DOWN, the network configuration may need rebuilding. This typically requires a VM restart or manual interface configuration.

Skip All of This: Deploy with an AI Agent

This guide exists as a tested, machine-readable recipe in the Massed Compute MCP. Instead of running commands manually, configure an AI agent to handle the network diagnostics automatically.

Add this configuration to your MCP client:

{
  "mcpServers": {
    "massed-compute": {
      "type": "http",
      "url": "https://vm.massedcompute.com/api/mcp",
      "headers": { "Authorization": "Bearer MC_TOKEN" }
    }
  }
}

Then say:

“Run network connectivity diagnostics on my Ubuntu VM. I need a structured report covering DNS resolution, egress HTTPS, routing table, listening ports, and firewall status. The VM is SSH-accessible but workloads are failing on outbound connections.”

The agent matches your request against the recipe catalog (tested June 10, 2026), connects to your running VM, executes the diagnostic commands above in sequence, and reports back with the structured network analysis. If any step fails, the agent stops and provides the exact error output for troubleshooting.

Ready to Debug Network Issues?

Get systematic network diagnostics without the manual command-line work. Launch your Ubuntu VM and let our infrastructure handle the connectivity analysis.

Think it. Build it. Scale it.

Quick Setup Guide

For rapid network diagnostics deployment:

  1. Ensure your VM is running and SSH-accessible
  2. Have your private key file path ready
  3. Note any specific URLs or services that are failing
  4. Run the diagnostic commands in sequence
  5. Look for the VM_NETWORK_CONNECTIVITY_OK success token
  6. Analyze the structured output for DNS, egress, and firewall issues

The entire diagnostic process takes 5-10 minutes and requires no package installations or configuration changes on your VM.

Frequently Asked Questions

1. Do these diagnostics require sudo access?

Most diagnostic commands run without sudo. Firewall status checks may show limited information without elevated privileges, but the core network tests (DNS, egress, routing) work with standard user access.

2. Will this change my VM’s network configuration?

No, these are read-only diagnostics. The commands only gather information about your current network state without modifying DNS settings, firewall rules, or routing tables.

3. What if my VM can’t reach the diagnostic URLs?

That’s exactly what we’re trying to identify. Failed connections to test URLs indicate egress filtering, DNS issues, or firewall blocking that you can then address with your cloud provider’s network security settings.

4. Can I customize which URLs to test for egress?

Yes, replace the default URLs (huggingface.co, pypi.org, github.com) with your specific failing endpoints. The diagnostic pattern works for any HTTPS destination.

5. How do I interpret the network diagnostic output?

Look for timeouts in DNS lookups, connection refused errors in HTTPS tests, missing default routes in the routing table, and unexpected listening services in the port audit. Each section provides specific clues about network problems.