Troubleshoot firewall blocking JMS connections
Check if this is still an issue in EAP 6 Firewall blocking JMS connections in JBoss EAP Article ID: 44082 - Created on: Aug 10, 2009 3:39 PM - Last Modified: Mar 28, 2011 11:32 AM Issue JMS port dynamically changes and new port is blocked by firewall. New port can be seen via netstat on server side. Client side can be seen trying to connect to the new port, but the connection gets stuck in at SYN_SENT state due to firewall blocking. Environment JBoss Enterprise Application Platform (EAP) 4.3 5.0 Resolution The "serverBindPort" and "secondaryBindPort" for JBoss Messaging must be open on the firewall. These are configured in EAP 4.3: /server//deploy/jboss-messaging.sar/remoting-*bisocket-service.xml EAP 5.0: /server//deploy/messaging/remoting-*bisocket-service.xml If the "secondaryBindPort" is not explicitly configured then a random port will be used instead. If NAT is occurring on the firewall configure the secondaryConnectPort to the port on the firewall which is open from the client's perspective. Note: If the Service Binding Manager is in use then the bindings XML file must be configured as described rather than remoting-*bisocket-service.xml. See example Also, ensure that the proper ports for JNDI are open on the firewall as well. These will be 1098 and 1099 (or 1100 and 1101 for HA-JNDI) customarily. Root Cause Did not set secondaryBindPort to a value opened through the firewall. Set secondaryBindPort, but also set secondaryConnectPort to a different value even though NAT was not taking place Diagnostic Steps Examine the JBoss Messaging remoting-bisocket-service.xml and remoting-sslbisocket-service.xml (See the online documentation for remoting-bisocket-service.xml details) remoting-[ssl]bisocket-service.xml did not have secondaryBindPort set. Had them set it to a port open through firewall and retry. Retry failed, examined updated remoting-[ssl]bisocket-service.xml. Had set secondayConnectPort to a value differing from secondaryBindPort. Determined that they did not have Network Address Translation (NAT) taking place on firewall so they should remove the secondaryConnectPort setting and retry. Used netstat to examine socket ports being opened between client and server