Accessing JBoss on RHEL/CentOS — Firewall Gotcha (and the Right Way to Handle It)

While setting up JBoss (with its bundled Tomcat) on a freshly installed Red Hat–based system, everything appeared to be running correctly. The service started cleanly, and the default web interface was bound to port 8080 as expected.

However, when attempting to access the application from a remote machine, the connection failed.

After a bit of troubleshooting, the issue turned out to be straightforward: the system firewall was blocking inbound traffic on port 8080.

At the time this was originally written, the quickest solution was simply to disable the firewall entirely. That worked—but it is not recommended practice today.

Legacy Approach (What I Did Back Then)

On older systems such as CentOS/RHEL 4–6, firewall management was handled via iptables.

The following commands were used to save the current rules, stop the firewall, and disable it at boot:

service iptables save
service iptables stop
chkconfig iptables off

For newer systems at the time (RHEL/CentOS 7/8), the equivalent using firewalld was:

systemctl stop firewalld
systemctl disable firewalld

This immediately allowed access to the JBoss web console—but at the cost of completely removing network protection.

Recommended Approach (Open Only What You Need)

Instead of disabling the firewall, the proper solution is to allow the required port.

For RHEL/CentOS 7/8+:

firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

For older systems using iptables:

iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
service iptables save

Why This Matters

Disabling the firewall may seem like a quick fix, but it exposes the system unnecessarily. Opening only the required ports maintains security boundaries, limits the attack surface, and aligns with best practices for both lab and production environments.

Closing Thoughts

This was one of those early lessons that “worked at the time,” but didn’t age well. It’s a good reminder that getting something running and securing it properly are two different steps—and both matter.

The firewall wasn’t the problem—it was doing exactly what it was supposed to do.