Supervisor Cluster Login Failure: "TLS handshake timeout" to NSX Load Balancer VIP

Products

• VMware NSX

Issue/Introduction

• During a new VCF/Supervisor cluster deployment, administrators are unable to authenticate using the kubectl vsphere CLI plugin. The connection times out attempting to reach the NSX Load Balancer VIP.
  
  
• Error/Log Signature: Executing the login command with verbosity (-v 10):

kubectl vsphere login --server=<supervisor_ip> -u [email protected] --insecure-skip-tls-verify -v 10

DEBU[2026-02-06 09:56:33.318] Trying to login to nsx_loadbalancer_vip
WARN[2026-02-06 09:56:43.328] Error occurred during HTTP request: Post "https://nsx_loadbalancer_vip/wcp/login": net/http: TLS handshake timeout
ERRO[2026-02-06 09:56:43.328] Login failed: Post "https://nsx_loadbalancer_vip/wcp/login": net/http: TLS handshake timeout
Failed to login to supervisor cluster using nsx_loadbalancer_vip. Please check network connectivity. Not all cluster/workload sessions were established.

 

Environment

VMware NSX

Cause

The root cause is due the Data Plane MTU Mismatch at the Physical Network.

The TLS handshake timeout is a secondary symptom of underlying packet loss in the data plane. During a TLS handshake, the load balancer sends its certificate chain, resulting in a large payload. In an NSX environment, this payload is encapsulated via Geneve.

If the physical infrastructure (switches, routers, or firewalls) is not configured to handle Jumbo Frames (typically MTU 9000), these large encapsulated packets are silently dropped.

Resolution

The physical network infrastructure (specifically the physical firewall and intervening routing boundaries) must be reconfigured to uniformly support Jumbo Frames.

1. Align Underlay MTU: Modify the physical firewall, routers, and switchports in the path to support an MTU of at least 1700 bytes (9000 bytes is the VMware recommended standard for Geneve overlay traffic).

2. Verify NSX Global MTU: Ensure the NSX Global MTU setting matches the intended physical network design.

3. Validate Datapath Resolution: From the ESXi shell of the affected Host Transport Nodes, execute a non-fragmented jumbo ping to the Edge TEPs:
   vmkping ++netstack=vxlan -d -s <MTU - 28> <Destination_Edge_TEP_IP>
   
   (Note: For an MTU of 9000, use -s 8972 to account for ICMP/IP headers).

Additional Information

Suggestion of Datapath Isolation Testing Results:

1. L2 TEP to TEP (Same VLAN): PASS (Indicates local switchports support Jumbo frames).

2. L3 Edge TEP to Host TEP: FAIL (Indicates L3 boundary drop).

3. Host/Edge TEP to Physical Gateway: FAIL for payloads > 1472 bytes.

From the above test, the physical firewall was dropping Geneve-encapsulated frames exceeding the standard 1500-byte MTU, stalling the TLS handshake.

• Check the NSX MTU References:
  • Troubleshoot VKS Cluster Networking Errors (Check Supervisor NSX Networking Stack)
  • Troubleshooting MTU issues and fragmentation in NSX fabric