Troubleshoot Network

Connections from an instance to internet addresses time out, or nothing on the internet can reach the instance.

Internet access needs every link of the path to be in place. One of them is missing.

Check each item in order:

1. The VPC has an Internet Gateway: origin network get-internet-gateway --vpc-urn <vpc-urn>. See Attach and detach an Internet Gateway.
2. The instance has a way out. Either its network interface has a Floating IP (list-floating-ips shows the interface in networkInterfaceUrn), or its subnet’s route table has a 0.0.0.0/0 route to a NAT gateway. Without one of these, it has no internet access. See Floating IPs and NAT gateways.
3. The subnet’s route table has a 0.0.0.0/0 route to the Internet Gateway or to a NAT gateway. Check with get-subnet (its routeTableUrn) and get-route-table. See Route tables.
4. The subnet’s network ACL has egress rules that allow the traffic to the internet, including replies to inbound connections. See Network ACLs.
5. The instance’s security groups allow the traffic. For inbound connections, a group needs an ingress rule for the port and the client’s address range; the default group has them only for SSH, HTTP, HTTPS and ICMP. See Security groups.
6. The instance launched with an automatic public IP actually got one. If no address was available at launch, the instance runs without one. Associate a Floating IP by hand.

An instance trying to reach an internet address over IPv6 either gets an immediate ICMPv6 administratively prohibited error, which many clients report as Permission denied, or waits until the connection times out.

Instances can’t reach the internet over IPv6. Which of the two you see depends on the VPC’s IPv6 range.

Let the client fall back to IPv4, or configure the guest to prefer IPv4. Don’t retry over IPv6. See VPC and subnet addressing.

Instances in the same subnet reach each other, but connections to instances in another subnet of the same VPC time out.

Traffic between subnets goes through the VPC router, which serves a VPC only while it has an Internet Gateway attached. If the VPC has one, a network ACL or security group may deny the traffic.

1. Attach an Internet Gateway to the VPC if it has none. See Attach and detach an Internet Gateway.
2. Check both subnets’ network ACLs: the source subnet needs an egress rule and the destination subnet an ingress rule, for both the request and the reply. See Network ACLs.
3. Check the security groups of both instances.

create-vpc fails with no default private IPv4 range is available for another VPC in this organisation; specify an IPv4 CIDR for this VPC explicitly.

The platform picks default ranges from 16 /16 ranges, and your organization’s VPCs already use them, or the random choice found no free one.

Run create-vpc again with --ipv4-cidr and a private range between /16 and /28. See VPC and subnet addressing.

delete-subnet or delete-vpc fails, naming a network interface or a NAT gateway.

An attached network interface or a NAT gateway is still in the subnet or VPC.

1. For a network interface, terminate the instance that uses it. See Terminate an instance.
2. For a NAT gateway, remove the routes that name it, then delete it. See Delete a NAT gateway.
3. Run the delete again. See Delete a subnet or VPC.

An instance connects to the Floating IP of another instance, or to its own, and the connection hangs. The same connection from outside the platform works, or the connection works by private address.

One of two things:

• The server’s security groups don’t allow the caller’s public address. Traffic through a Floating IP carries a public source address, which rules that name a security group don’t match.
• The caller is in a different VPC from the Floating IP. A Floating IP is reachable from inside the platform only from its own VPC.

Add an ingress rule for the caller’s public address (its own Floating IP, or the Floating IP it calls), or connect by private address within the VPC. From another VPC, connect from outside the platform instead. See Floating IPs.

create-nat-gateway fails.

The message names one of these:

• a nat gateway must live in a public subnet: the subnet’s route table has no default route to an Internet Gateway.
• this floating ip is associated with a network interface: the Floating IP is in use by an instance.
• this floating ip already backs nat gateway: each gateway needs its own Floating IP.
• PAYMENT_METHOD_REQUIRED: the billing account your project is charged to has no verified payment method. See Add a payment method.
• A quota message naming NAT gateways.

Create the gateway in a subnet that uses the main route table of a VPC with an Internet Gateway, or add a default route to the Internet Gateway to the subnet’s table. Use a Floating IP that’s allocated and unassociated, or allocate a new one. See NAT gateways.

The CLI exits with the following required arguments were not provided, naming <--rule <RULES>|--no-rules>, or <--egress-rule <EGRESS_RULES>|--no-egress-rules> and its ingress counterpart.

These commands replace the whole rule list, so they require you to state the new list. Leaving it out would delete every rule.

Give every rule you want to keep with --rule, --ingress-rule or --egress-rule. If you do want an empty list, give --no-rules, --no-ingress-rules or --no-egress-rules. See Rule sets are replaced as a whole.