Neo4j cluster and firewalls

This article summarizes the required and optional communication channels for a Neo4j enterprise cluster and provides some sample rules. For the firewall rules I’m using Ubuntu’s ufw package.

As a sample setup we assume the following servers. All of them have 2 network interfaces, eth0 is for communication with outside world, eth1 is for cluster communication.

name eth0 ip address eth1 ip address

access to REST interfaces

By default Neo4j listens on port 7474 for http and on 7473 for https style requests to the rest api. To allow for remote access you need to set in

org.neo4j.server.webserver.address= // or for all interfaces

Inbound access needs to be granted using

ufw allow in on eth0 proto tcp from any to any port 7474

When using SSL the rule needs to hit port 7473 instead.

cluster communication

A Neo4j cluster uses two different communication channels: one for cluster management (joining/leaving the cluster, master elections, etc.) and one for transaction propagation. By default ports 5001 and 6001 are used. On all cluster members we need to allow inbound and outbound traffic for these to the other cluster members:

# cluster management: inbound and outbound
ufw allow in on eth1 proto tcp from to any port 5001
ufw allow out on eth1 proto tcp to port 5001

# transaction propagation: inbound and outbound
ufw allow in on eth1 proto tcp from to any port 6001
ufw allow out on eth1 proto tcp to port 6001

online backup

Neo4j enterprise supports online backup – the default port for this 6362. To enable remote backup you need to set in

online_backup_server= // or for listening also on eth0

The corresponding ufw command is:

ufw allow out on eth1 proto tcp to port 6362
ufw allow in on eth1 proto tcp from to any port 6362

remote shell

This is pretty tricky. Under the hoods neo4j remote shell uses Java RMI. When a new connection is established the client communicates with server:1337. During this control session a secondary port is negotiated – unfortunately a random port is used. So the client opens a second connection to the server with the negotiated port – therefore we have to open up basically all ports for the ip addresses acting as shell clients:

ufw allow in on eth1 proto tcp from  
ufw allow out on eth1 proto tcp to 

There might be a more sophisticated approach by implementing a custom RMISocketFactory and register it with the JVM as described in the JVM docs. I have not yet tried this, so if you have explored that path yourself I’d appreciate to hear your solution to this.


remove the passphrase from a pkcs12 certificate

PKCS12 defines a file format that contains a private key an a associated certifcate. These files might be used to establish some encrypted data exchange. In the current use case, OpenVPN is used to connect to a remote network. The pkcs12 is being issued by a CA (certificat authority) tool. For security reasons, the private key contained in the pkcs12 is normally protected by a passphrase. This has the downside, that you need to manually type the passphrase whenever you need to establish the connection. But there’s a way to get around this. OpenSSL is a swiss-army-knife toolkit for managing simply everything in the field of keys and certificates. Since it’s a command line tool, you need to understand what you’re doing. So it took me a little to figure out how to remove a passphrase from a given pkcs12 file. Here’s what I’ve done:

openssl pkcs12 -in protected.p12.orig -nodes -out temp.pem
openssl pkcs12 -export -in temp.pem -out unprotected.p12
rm temp.pem

The first command decrypts the original pkcs12 into a temporary pem file. pem is a base64 encoded format. The second command picks this up and constructs a new pkcs12 file. During this, the new passphrase is asked. By simply typing ‘return’ here, it set to nothing. When using unprotected.p12 in the OpenVPN connection, you’re no longer asked for a passphrase.

A word of warning: I do not recommend doing this generally. From my perspective it’s okay, if your unprotected pkcs12 file is protected by other means, e.g. harddisc encryption.