Connecting my Server pc with public ip to Hive Cloud MQBroker

HiveMQ Cloud
1

Hi

I’m trying to connect my server PC to a HiveMQ Cloud broker over MQTT/TLS (port 8883). However, the connection is timing out.

To troubleshoot, I tried retrieving the server certificate using:

openssl s_client -connect <HiveMQ_Cloud_Server_Address>:8883

but the command eventually returns a connection timeout instead of showing the TLS certificate.

One thing I’m wondering is whether my network configuration could be the cause. My server’s network interface is connected through a DMZ bridge.

Could the DMZ bridge or its associated firewall/NAT configuration prevent outbound connections to port 8883 or interfere with the TLS handshake? If so, what specific network settings or checks should I perform to verify whether the DMZ bridge is causing the issue?

i also checked with the below command

sudo ufw status verbose

it returned that 8883 port is allowed

8883/tcp ALLOW IN Anywhere 
8883 ALLOW IN Anywhere

How to resolve this to get successful TLS handshake

Thankyou

2

Hello Parvathy,


|

  • |

Thanks for reaching out on our HiveMQ Community Forum.

Based on the behaviour you described, the most likely issue is in the network path rather than with the HiveMQ Cloud broker certificate itself.
Since openssl s_client -connect <HiveMQ_Cloud_Server_Address>:8883 is timing out before any certificate is returned, this usually indicates that the TCP connection to port 8883 is not being established successfully.
Regarding your ufw output: the rule you shared shows that port 8883 is allowed for inbound traffic on your server. For this use case, the more important point is whether your server can establish outbound TCP connections to the HiveMQ Cloud endpoint on port 8883, and whether the return traffic is allowed back through the network path.

Because your server is connected through a DMZ bridge, it is possible that the DMZ firewall, NAT, or routing configuration is affecting the connection. In particular, please verify the following:

  • Outbound TCP traffic from the server to the HiveMQ Cloud hostname on port 8883 is allowed
  • Return traffic for that session is permitted through the firewall/NAT
  • The DMZ subnet has correct internet routing/NAT configured
  • No TLS/SSL inspection or proxy is interfering with MQTT over TLS traffic
  • No upstream firewall rule or ACL is blocking the destination hostname or resolved public IP
    To investigate further, please run the following checks from the affected server:
nslookup <HiveMQ_Cloud_Server_Address>
dig <HiveMQ_Cloud_Server_Address>
nc -vz <HiveMQ_Cloud_Server_Address> 8883
openssl s_client -connect <HiveMQ_Cloud_Server_Address>:8883 -servername <HiveMQ_Cloud_Server_Address> -showcerts

If nc or openssl times out, that would strongly suggest a network connectivity issue between the server/DMZ and the HiveMQ Cloud endpoint.
If possible, it would also be helpful to compare the same openssl s_client test from another network where the connection is known to work. If the connection succeeds from a different network but times out from the DMZ-connected server, that would further confirm that the issue is related to the DMZ network path or its firewall/NAT configuration.
If needed, you can also capture traffic while testing to confirm whether the TCP handshake completes:

sudo tcpdump -ni any host <resolved_broker_ip> and port 8883

In summary, the next step is to validate outbound connectivity from the DMZ-connected server to the HiveMQ Cloud endpoint on port 8883.
If the TCP connection cannot be established, the issue will need to be resolved in the DMZ firewall/NAT/routing configuration before a successful TLS handshake can occur.

Regards,
Gil