Error: Heartbeating between NSX management node and host <host-FQDN or IP, moref...> is down firewall reset VMware NSX

Products

• VMware NSX

Issue/Introduction

• ESXi hosts show a status of Disconnected in the NSX Manager UI.
• Transport node reports alarms like "Control Channel To Transport Node Down Long" or "Management Channel to Transport Node Down Long"
• A critical error is raised in NSX UI when investigating "down" state of ESXi Transport Node: Heartbeating between NSX management node and host #### is down.
• Running nsxcli -c get controllers on the ESXi host shows a status of disconnected and a failure reason of OTHER_ERROR:
  

   Controller IP    Port     SSL         Status       Is Physical Master   Session State  Controller FQDN           Failure Reason
    <IP Address>    1235   enabled      not used            false              null              NA                       NA
    <IP Address>    1235   enabled    disconnected           true              down              NA                  OTHER_ERROR
    <IP Address>    1235   enabled      not used            false              null              NA                       NA
  

• Running nsxcli -c get managers on the ESXi host shows the NSX Managers in Standby (NSX-RPC) status.
  
  
• The /var/log/nsx-syslog.log on the ESXi host contains errors such as: Couldn't connect to 'ssl://####:1234' (error: 104-Connection reset by peer)
• The NSX Manager /var/log/syslog log show SSL handshake failures: 

   NSX 2022 - [nsx@4413 comp="nsx-manager" subcomp="appl-proxy" s2comp="nsx-net" tid="2063" level="ERROR" errorCode="NET4"] NetTransport[1] Accept on endpoint 'ssl://0.0.0.0:1234' failed with error 104-Connection reset by peer from remote endpoint 'ssl-tcp://<IP Address>:57110'
   NSX 2022 - [nsx@4413 comp="nsx-manager" subcomp="appl-proxy" s2comp="nsx-net" tid="2063" level="ERROR" errorCode="NET4"] NetTransport[1] Accept on endpoint 'ssl://0.0.0.0:1234' failed with error 104-Connection reset by peer from remote endpoint 'ssl-tcp://<IP Address>:61742'

• Netcat connection is successful from ESXi host to NSX Managers:
  

  # nc -zv <NSX Manager FQDN> 1234
  Connection to <NSX Manager FQDN> 1234 port [tcp/*] succeeded!
  
  # nc -zv <NSX Manager FQDN> 1235
  Connection to <NSX Manager FQDN> 1235 port [tcp/*] succeeded!

• Confirmed that certificates are valid on ESXi hosts:
  

  openssl x509 -in /etc/vmware/nsx/host-cert.pem -noout -text | grep -A 2 "Validity"
          Validity
              Not Before: Jul  9 08:47:32 2026 GMT
              Not After : Jul  6 08:47:32 2036 GMT

Environment

• VMware Cloud Foundation (VCF) 9.0.1
• VMware NSX 4.x 
• ESXi 8.0 / 9.0

Cause

A physical firewall between the ESXi hosts and the NSX Managers is actively breaking the SSL connection. Because both the ESXi host and the NSX Manager simultaneously record a "104-Connection reset by peer" error, this indicates that the intermediary firewall is intercepting the traffic and sending TCP RST (Reset) ACK packets to both endpoints to tear down the session.

This occurs because the connections utilize random ephemeral source ports for the SSL handshake. While basic routing and destination ports are open, the firewall's strict port policies interpret the random source ports as unauthorized traffic, thereby interrupting the secure session establishment.

Resolution

1. Verify if an intermediary firewall is performing SSL inspection or strict source port filtering on ports 1234 and 1235.
2. Update firewall security rules to allow traffic from ESXi management/transport IPs to the NSX Manager VIP and individual node IPs using any source port.
3. Ensure the firewall allows persistent SSL traffic without interference during the handshake phase.
4. Verify connectivity by running the following commands on the affected ESXi host: nsxcli -c get managers nsxcli -c get controllers
5. If the host does not automatically reconnect after the firewall change, navigate to System > Fabric > Nodes > Host Transport Nodes in the NSX Manager UI, select the host, and click Resolve.

Additional Information

Control Channel To Transport Node Down Long Alarm
Control Channel To Transport Node Down Too long due to DNS connectivity issue.
Heartbeating between NSX management node and host &lt;host-UUID&gt; is down.
"Control Channel To Transport Node Down Long" or "Management Channel to Transport Node Down Long" alarms for removed Transport Nodes
For general information on retrieving logs, see How to retrieve NSX-T logs from ESXi hosts.