Port requirements for a Light-Node?

Question

For a light client (geth --light or parity --light) running the light client protocol what are the port requirements?

Incoming: Does a light client expose a port where he accepts incoming connections and that need to be opened in the firewall (I would assume not)?

Outgoing: And vice-versa outgoing which ports need to be opened so that a light client can connect to other full-node peers?

Answer 1

In my experience, you don't need to open any ports. geth will make outgoing connections, and this is enough to populate the local datastore.

If you want other nodes to be able to open a connection to your node, allow:

• incoming to 30303 TCP
• incoming to 30303 UDP (for node discovery)

I can't think why any remote node would want to connect to a light node, however opening these ports did seem to help our light node find peers.

---

Most firewalls only block incoming connections, and allow all kinds of outgoing connections. But if you do need to whitelist outgoing connections explicitly, then you should allow:

• outgoing to 30303 TCP
• outgoing to 30303 UDP (for node discovery)

This should provide access to most nodes (those using default ports) but not nodes which have been configured to run on custom ports.

---

Finally, if you want to use RPC from a remote machine, you may need to open the RPC port:

• incoming to 8545 TCP (Note: security concerns!)

Note that doing this would allow anyone to use your port 8545. Therefore you should not unlock any wallet on your node, because someone could connect to port 8545 and transfer funds out of the wallet! go-ethereum (get) does not password-protect the RPC port.

Even if you don't unlock any wallet on the node, leaving the RPC port open (certainly at the default port number) will result in lots of attackers trying to abuse your node, effectively resulting in a denial of service. (It might take a couple of days for them to discover your node, but once they do it will get hammered!)

Mitigations to that are:

1. Only allow connections to the RPC port from localhost (recommended)
2. Don't unlock any wallet on the node. Instead keep your private keys separately, and sign transactions before sending them to the node. (recommended alternative to suggestion 1)
3. Only allow connections to the RPC port from IPs you control (should reduce spammers, but not entirely secure on its own: IPs can be spoofed by a middleman on the network)
4. Use a non-standard RPC port number (might help a little, but not really a solution)
5. Use a reverse proxy like nginx for the RPC port, and make nginx require authentication

I suggest you choose option 1, or combine 2 and 3. Option 5 seems reasonable, but I never tried it.