Exploring Eth2 – Why Open Ports Matter

One of the most commonly overlooked steps when setting up a beacon node is to setup port forwarding on your router to ensure that other nodes can connect in to yours. This is often overlooked, or not done correctly, because there are so many different routers, all with different, fiddly interfaces that providing simple instructions is essentially impossible and because your node will generally work even without it by connecting outbound to other peers even though none can connect inbound.

Unfortunately, this means a lot of nodes on the beacon chain don’t accept incoming connections and that’s bad for the health of the network in two ways:

1. Reduced efficiency
2. Increased risk of censorship

The efficiency of the beacon chain’s gossip network is reduced because two nodes with closed ports can never connect to each other. So as the percentage of nodes with open ports drops, the network gradually morphs from a mesh topology to a star topology. Gossip messages then have to route through a relatively small number of “super nodes” (those with open ports) which then forward it on to the nodes. It works, but messages propagate slower.

It’s also much harder for nodes to join the network because they need to find nodes that have open ports to connect to, and most of those are already at their peer limit so are rejecting connections. That causes a lot more discovery traffic and connection attempts than necessary.

The move towards a star topology also increases the risk of censorship. With messages having to route through a smaller number of nodes, censorships only need to target those nodes with open ports rather than needing to disrupt communications of all nodes on the network. The fewer nodes with open ports, the easier such attacks are.

So if you’re running a beacon node, ensure that your ports are correctly forwarded and remember that both TCP and UDP need to be forwarded to correctly allow incoming connections. While there are only tools to check TCP connectivity, I don’t know of any that will correctly check UDP connectivity because the discovery system deliberately won’t reply to invalid packets. Since most UDP tests just send a random packet and report success if it isn’t explicitly rejected, they don’t confirm that the packet actually reached the discovery system and will pass even if the packet was silently dropped by a firewall which is very common.

The most definitive way to check your port forwarding is working is to check that you have a mix of incoming and outgoing peer connections. For clients supporting the standard REST API (all of them now I think 🎉) you can run:

curl http:/localhost:5051/eth/v1/node/peers | jq

You should see at least some peers reported with "direction": "inbound". If not, your port forwarding is not working correctly and peers can’t initiate connections to your node.