Troubleshooting node networking and connectivity

Start with two checks: the node reads Running, and its security group allows the port you need. Most connection failures come from one of those two. The entries below cover SSH, RDP, and SQL Server connections, and IP addresses or VPCs that will not attach or detach.

SSH or RDP connection fails

SSH and RDP connect straight to the node over the network, whatever status the portal shows, so the cause is on the network path or inside the node. Locking the node, for example, leaves both open.

Check, in order:

1. The node is Running, and the address you are connecting to matches the public IP shown on the node’s Network tab.
2. The security group attached to the node allows the port you are using: 22 for SSH, 3389 for RDP. A default security group allows all inbound and outbound traffic; if you attached a custom one, confirm it still allows that port.
3. Inside the node, its own firewall (Windows Firewall, ufw, iptables, or similar) allows the same port.

If all three check out, the network path outside E2E is worth checking next: a local firewall or an ISP block can produce the same symptom.

If you still cannot get in, open Access Console instead; see Open a node’s console. It reaches the node’s screen directly in the browser, without SSH or RDP, so you can check its firewall and network settings from inside it.

If the console shows the node itself is not responding, it may have run out of memory or disk, or the kernel may have stopped. A console full of out-of-memory messages, or a blank screen that takes no input, is a sign of this. Check the memory and storage charts on the node’s details page for the time it stopped answering, then reboot it from the Actions menu; see Reboot a node. If a full disk or a busy process was the cause, Troubleshooting node performance and resources has the fix, so it does not happen again.

If a firewall or network change you made is what cut off access, and you cannot get in through Access Console either, contact support with the node’s name and the change you made. A CDP Backup restore copies the files you choose into a separate folder on the node and leaves its settings as they are, so it cannot undo the change.

Reachable but slow, or intermittent packet loss

Run ping against your node and a well-known destination, such as 8.8.8.8, at the same time, so you are comparing like for like:

ping <node-ip>
ping 8.8.8.8

If both show loss, the problem is on your own network, not the node. If only the node shows loss, the problem sits between you and E2E’s network; run a traceroute to the node and send both ping results to support along with it. Repeat the test from a different network connection first if you can, such as switching from Wi-Fi to a phone’s mobile data: that rules out a fault specific to your own ISP before you escalate it.

SQL Server connection fails

A SQL Server node needs its security group to allow TCP port 1433 from the sources you are connecting from; Windows Firewall alone is not enough. The security group and Windows Firewall filter traffic at different layers. A rule in one does not cover the other, so both need to allow the port before a connection gets through. Add or confirm that rule on the node’s security group, then try connecting again as described in Connect to a SQL Server node.

IP address will not attach or detach

Locking holds the node’s configuration as a whole, network attachments included, so no IP (public, add-on, IPv6, or floating) can be attached or detached until the lock comes off. Remove the lock from the node first, then attach or detach the IP from the node’s Network tab:

• Attach a reserved IP to a node
• Detach a node’s public IP
• Attach an IPv6 address to a node
• Attach a Floating IP to a node

Nodes on the same VPC cannot reach each other

Traffic over a VPC goes node to node on private addresses, so each step on that path has to allow it. Check, in order:

1. Both nodes show the VPC on their Network tab, with a private IP from it.
2. You are connecting to the other node’s private IP from that VPC, not its public IP.
3. The security group on the receiving node allows the port from the sending node’s private address.
4. The receiving node’s own firewall allows the same port, and the service there is listening on the private address, not only on 127.0.0.1.

A preferred IP you choose when attaching a VPC has to sit inside the subnet you picked and must not already be in use by another node; pick another address, or leave the field empty and let the VPC assign one.

VPC does not appear in the attach list

Only a VPC that is active and in the same region as the node shows up when you are choosing one. A VPC is a network tied to one region. Attach one that is active in the node’s own region, or create a new one there. See Attach a node to a VPC.

If you still cannot reach the node, contact support with its name, IP address, and CRN, your ping and traceroute results, and when the problem started.