Skip to main content

Troubleshooting Node Networking

This guide covers issues with public IPs, Add-on IPs, VPCs, private IPs, and private access to your node. Most networking problems trace back to one of three things: the node family does not include the address by default (E1 is the common case), the requested address is not available in the same project/location, or the path is blocked by a security group, OS firewall, or route configuration.

Common Issues​

IssueWhat to check
Public IP is missingCheck whether the node family includes a default primary public IP. E1 nodes do not include one by default. Attach a primary public IP if public access is required.
Public IP cannot be detachedDetach all Add-on IPs first, then retry detaching the primary public IP. Also check node state, lock status, and whether another action is in progress.
Add-on IP cannot be attachedConfirm the node has a primary public IP, the Add-on IP is available in the same project/location context, and the node is in a valid state.
VPC does not appearConfirm the VPC is active, in the expected location, and compatible with the selected node.
Preferred private IP is rejectedConfirm the IP is inside the selected subnet, is a private IPv4 address, and is not already in use.
Private access failsCheck VPC attachment, route path, security group rules, OS firewall rules, and source network reachability.

Details​

Public IP is missing​

Most node families (C3, M3, SDC3, WSDC4) are launched with a default primary public IP. The E1 family is the exception — E1 nodes do not include a public IP by default. If your E1 node needs to be reached over the public internet, attach a primary public IP from the node's action menu. An Add-on IP can only be attached after a primary public IP exists on the node.

Public IP cannot be detached​

The primary public IP cannot be detached while any Add-on IPs are still attached to the node — Add-on IPs depend on the presence of the primary. Detach every Add-on IP first, then retry detaching the primary. Also confirm the node is in a valid state (not mid-operation), is not locked, and that no other action is currently in progress on the node.

Add-on IP cannot be attached​

Three conditions must all be true to attach an Add-on IP:

  1. The node already has a primary public IP attached.
  2. The Add-on IP is available in the same project and location as the node.
  3. The node is in a valid state (typically Running and unlocked).

VPC does not appear in the selection list​

When the VPC dropdown does not show the VPC you expect, confirm that the VPC is active, is in the same location as the node, and is compatible with the node family. VPCs from a different location or project will not appear.

Preferred private IP is rejected​

When you specify a preferred private IP for the VPC interface, the value must satisfy all of the following:

  • It must be inside the selected subnet's CIDR range.
  • It must be a private IPv4 address.
  • It must not already be in use by another resource on that VPC.

Private access fails​

If you cannot reach a node over its private interface, walk through the path step by step:

  1. VPC attachment — confirm the node is attached to the expected VPC.
  2. Route path — confirm the route table on both ends allows traffic between source and destination subnets.
  3. Security group rules — confirm the inbound rules on the node's security group allow the protocol, port, and source.
  4. OS firewall rules — confirm the node's OS firewall (iptables, firewalld, Windows Firewall) is not dropping the traffic.
  5. Source network reachability — confirm the source machine itself can route to the VPC range (peering, VPN, or in-VPC).

Verifying Network Reachability with Ping and Traceroute​

When troubleshooting reachability, ping and traceroute are your fastest diagnostic tools.

Ping sends an ICMP Echo Request to the destination and measures the round-trip response time. It tells you whether the host is reachable and gives a rough estimate of latency.

ping IP-ADDRESS -c 100

Traceroute displays the path packets take from your machine to the destination, listing each hop and its transit delay. It is the right tool for locating where in the path traffic is being dropped.

traceroute IP-ADDRESS

Replace IP-ADDRESS with the actual IP of the host you want to test.

Comparative Analysis Against Google DNS​

If only your node is unreachable while everything else works, the problem is likely at the node or its network. If everything is unreachable, the problem is local. A comparative test against a known-good destination like Google DNS (8.8.8.8 or 8.8.4.4) helps you tell them apart.

ping 8.8.8.8 -c 100
traceroute 8.8.8.8

If Google DNS is reachable but your node is not, send the parallel ping report and the traceroute for your node to cloud-platform@e2enetworks.com.

Last updated on May 15, 2026.