Learn RabbitMQ - Network Configuration & Firewall

#Introduction

RabbitMQ is a creature of the network: every feature we've discussed — AMQP, the Management UI, clustering, Prometheus metrics, MQTT and STOMP plugins — all run over specific ports. If ports aren't configured and protected properly, two problems lurk: services become inaccessible, or worse, the broker becomes accessible to unauthorized people.

This episode maps out all the ports RabbitMQ uses, then discusses the bind address — determining which interface serves which connections. Finally, we put together firewall rules for single nodes and clusters, including security groups in the cloud and VPC peering considerations.

The end goal is simple: only the right networks can reach each port, and no port is open more than necessary.

#Port Configuration

#RabbitMQ's Main Ports

The most commonly used ports:

Plugin ports: MQTT on 1883 (and 8883 for TLS), STOMP on 61613, Web-STOMP on 15674, and MQTT over WebSockets on 15675.

#Verifying Open Ports

Check which ports are currently listening:

ss -tlnp | grep -E "5672|15672|25672|4369"

The ss -tlnp command shows active TCP ports. If there's an unexpected port, disable the plugin or change its listener configuration.

#Network Topology

#Bind Addresses and Interfaces

By default RabbitMQ listens on all interfaces. Restrict it with listeners.tcp.ip to only serve specific interfaces:

listeners.tcp.default = 5672
listeners.tcp.ip = 192.168.50.10
listeners.ssl.default = 5671
listeners.ssl.ip = 192.168.50.10
management.tcp.ip = 192.168.50.10
management.tcp.port = 15672

With the configuration above, ports 5672, 5671, and 15672 can only be reached from the address 192.168.50.10 — not from all public interfaces.

#IPv4 vs IPv6 and DNS

RabbitMQ supports both IPv4 and IPv6. If you use hostnames in client connections, make sure DNS resolves to an address matching the bind address. A common mistake: clients use a hostname that resolves to IPv6 while the listener is only on IPv4 (or vice versa). To debug failed connections, check DNS resolution:

getent hosts rabbitmq.example.com

The getent hosts command shows the addresses resolved from the hostname — match them against the interface serving the port.

#Firewall Rules

#Rules for a Single Node

For a single node, ideal firewall rules restrict access per port:

• Port 5672/5671 (AMQP): only from the application subnet.
• Port 15672/15671 (Management): only from the operator network or VPN.
• Port 15692 (Prometheus): only from the Prometheus network.
• Other ports: no need to be public.

sudo ufw allow from 10.0.1.0/24 to any port 5672
sudo ufw allow from 10.0.2.0/24 to any port 15672
sudo ufw allow from 10.0.3.0/24 to any port 15692

#Rules for a Cluster

A cluster needs additional ports between nodes: 25672 for node communication, 4369 for epmd. The correct rule: these ports should only be accessible between cluster nodes, not from the general network:

sudo ufw allow from 10.0.0.0/16 to any port 25672
sudo ufw allow from 10.0.0.0/16 to any port 4369

epmd records node ports; make sure every node can reach the other nodes' epmd before forming a cluster (topic of episode 19).

#Cloud Security Groups and VPC Peering

On AWS/GCP, translate the rules above into security groups: create a dedicated RabbitMQ group with restricted inbound rules. For cross-VPC communication, use VPC peering and make sure route tables direct the broker subnet to the application subnet. Never open port 15672 to 0.0.0.0/0 — that's an open invitation to everyone on the internet.

#Conclusion

In episode 18 you mapped out all the RabbitMQ ports, configured bind addresses and interfaces, considered IPv4 vs IPv6 and DNS, and put together firewall rules for single nodes, clusters, and cloud environments.

Key takeaways:

• AMQP on 5672/5671; Management UI on 15672; Prometheus on 15692.
• Clusters need port 25672 and epmd 4369 between nodes.
• The bind address limits the interfaces serving connections.
• Match client DNS resolution with the bind address.
• Don't open the Management UI and Prometheus to public networks.
• Cluster ports should only be accessible between nodes.
• Cloud security groups restrict access per subnet and VPC peering.

In the next episode we will build RabbitMQ clustering — forming a multi-node cluster, node discovery mechanisms, securing it with the Erlang cookie, adding and removing nodes, and handling network partitions with the pause_minority, autoheal, and ignore modes. This is the first step toward high availability!