Configure ports and firewalls for improved peer-to-peer connectivity
Not familiar with nodes, networks, and related terminology? Consider reading Nodes and networks before proceeding.
In some cases, small changes to your port and firewall configuration can significantly improve your node's peer-to-peer connectivity. Improved peer-to-peer connectivity benefits the broader Ethereum ecosystem by making blockchain data more available, and it can also help your validator find more work (and earn a little more ETH).
In this how-to, we'll walk through the following tasks:
- Configure your firewall for improved peer-to-peer connectivity.
- Determine your IP addresses so you can configure your router and beacon node.
- Configure your router for improved peer-to-peer connectivity.
- Configure your beacon node to broadcast your public IP address.
- Verify your node's discoverability by using a TCP lookup tool.
Note that as long as you can complete the Status checklist without error, this isn't required. These are optimizations targeted at power users.
Configure your firewall
Your node and validator will try to establish several types of connections:
- Validator nodes try to connect to a single, dedicated beacon node. This beacon node can be local or remote.
- Beacon nodes try to connect to a single, dedicated execution node. This execution node can be local or remote.
- Beacon nodes try to connect to many peer beacon nodes.
- Execution nodes try to connect to many peer execution nodes.
To establish these connections, your client software needs to be able to send and receive messages through specific ports. As a security best practice, we recommend blocking inbound traffic across all local ports, allowing inbound traffic on a port-by-port basis.
The following firewall rules should be configured on any local operating system, third-party software, or hardware firewalls between your nodes and their internet connection:
| Port/protocol | Firewall rule | Reason/caveats |
|---|---|---|
8545/TCP | Block all traffic. | This is the JSON-RPC port for your execution node's Query API. You (and apps) can use this port to check execution node status, query execution-layer chain data, and even submit transactions. This port generally shouldn't be exposed to the outside world. |
3500/TCP | Block all traffic. | This is the JSON-RPC port for your beacon node's Query API. You (and apps) can use this port to check beacon node status and query consensus-layer chain data. This port generally shouldn't be exposed to the outside world. |
8551/TCP | Block all traffic. | Your beacon node connects to your execution node's Engine API using this port. Inbound and outbound traffic should be allowed through this port only if your local beacon node is connecting to a remote execution node. |
4000/TCP | Block all traffic. | Your validator uses this port to connect to your beacon node via gRPC. Inbound and outbound traffic should be allowed through this port only if your local validator is connecting to a remote beacon node. |
*/UDP+TCP | Allow outbound traffic. | To discover peers, Prysm's beacon node dials out through random ports. Allowing outbound TCP/UDP traffic from any port will help Prysm find peers. |
13000/TCP | Allow inbound and outbound traffic. | After we discover peers, we dial them through this port to establish an ongoing connection for libp2p and through which all gossip/p2p request and responses will flow. |
12000/UDP | Allow inbound and outbound traffic. | Your beacon node exposes this UDP port so that other Ethereum nodes can discover your node, request chain data, and provide chain data. |
30303/TCP+UDP | Allow inbound and outbound traffic. | 30303/TCP is your execution node's listener port, while 30303/UDP is its discovery port. This rule lets your execution node connect to other peers. Note that some clients use 30301 by default. |
Note that both consensus and execution clients allow you to customize many of these ports. The above table of rules is based on default port values.
When configuring Allow inbound rules, consider tying the rule to an IP address when possible. For example, if your beacon node on Machine A is connecting to a remote execution node on Machine B, Machine B's Allow inbound and outbound traffic over 8551 rule should be tied to Machine A's public IP address. More information about IP addresses and port forwarding is available below.
Determine your IP addresses
- Operating system:
- Linux, MacOS, Arm64
- Windows
- Network:
- Mainnet
- Sepolia
- Holesky
Configure your router
If you're running on a virtual public cloud (VPC) instance, you can skip this step.
To ensure that other peer nodes can discover your node, you may need to forward ports 13000/TCP and 12000/UDP using your router's admin interface. Every router is different, but the procedure is usually something like this:
- Determine your router's IP address
- Log in to your router's browser-based admin interface (usually something like http://192.168.1.1)
- Look for
Port Forwarding. - Configure a port forwarding rule with the following values:
- External port:
13000 - Internal port:
13000 - Protocol:
TCP - IP Address: The private IP address of the computer running your beacon node
- External port:
- Configure a second port forwarding rule with the following values:
- External port:
12000 - Internal port:
12000 - Protocol:
UDP - IP Address: The private IP address of the computer running your beacon node
- External port:
If your execution node, beacon node, and validator node are split across multiple machines, you may need to forward additional ports. Refer to the above table of firewall rules for information about specific ports that you may need to forward.
Broadcast your public IP address
Your beacon node will broadcast your static, public IP address to peer nodes if you configure either the following flags:
--p2p-host-ip=<your public IP>: Use this if you haven't configured a DNS record for your public IP. For example:--p2p-host-ip=67.127.151.89--p2p-host-dns="host.domain.com": For example:--p2p-host-dns=host.domain.com
Broadcasting your static IP can make your beacon node more discoverable, which benefits the Ethereum network by making consensus-layer blockchain data more available. Note that if you're using a dynamic IP address (this is usually the case by default), your node will lose its peers every time your ISP assigns your router/device a new IP address.
Verify your node's discoverability
Use the MX Toolbox TCP Lookup tool:
https://mxtoolbox.com/SuperTool.aspx?action=tcp%3a{Your-Public-IP-Address}%3a13000&run=toolpage
Note the above placeholder for Your-Public-IP-Address, and the specification of 13000/TCP.
If you see the following results, your beacon node is highly discoverable:
You can perform the same test using 30303/TCP to test your execution node's discoverability.
See Check your node and validator status for a comprehensive status checklist.