Downloads over HTTPS fail on VMs connected to NSX overlay segments
search cancel

Downloads over HTTPS fail on VMs connected to NSX overlay segments

book

Article ID: 414605

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • Workload VM connected to overlay segment is downloading a large file from internet via Edge or any other browser using https.
  • The download fails almost instantly.
  • The issue is observed in both scenarios: when the workload VM resides on the same host as the Edge and when it resides on a different host.
  • TLS/SSL in workload VM resets TCP connection when it received a corrupted packet but with valid L4 cksum.
  • Packet Capture in ESX host where Edge VM is hosted showing corrupted packet received from physical infra:

Environment

VMware NSX

Cause

Packets with wrong L4 cksum(corrupted) entered Edge via T0 VLAN uplink. Edge forwards the packet with Geneve encap without updating the inner cksum so that workload VM can detect corruption.

If Edge VM and workload VM are in different hosts, when packet received from Edge VM, Broadcom NIC in ESX host updates both inner and outer L4 cksums in Geneve packet based on payload which masks corruption. When packets received in workload VM, TCP/IP stack doesn't detect corruption since inner cksum was updated, but TLS layer detects it and closes TCP connection.

When Edge VM and workload VM are in same host and with Inter-TEP feature enabled, Geneve packet from Edge VM is locally delivered to workload VM without going through physical layer. In this scenario, VDL2 layer in ESX when forwarding packet to workload VM marks the packet with ckusm verified without validating the cksum with the assumption that Edge wouldn't send corrupted packet. Since packet is marked with cksum verified, workload VM's TCP/IP doesn't do cksum validation and pass the packet to TLS, which detects corruption and closes TCP connection.TLS/SSL in workload VM resets TCP connection when it received a corrupted packet but with valid L4 cksum.

Resolution

This workaround is to completely bypass the hardware checksum offloading at Broadcom NIC, so that only the outer checksum is updated by software checksum offloading emulation at ESX uplink. This workaround has performance impact on other VMs running on the same ESX host as the Edge VM.

  • On the ESX host of the Edge VM, use below command to disable hardware checksum offloading. This command enables both Geneve CSO/TSO software emulation and regular IPv4 CSO software emulation

localcli network nic software set --geneveoffload 1 --ipv4cso 1 -n <VMNIC_X>

  • Disable RX ckusm offloading on the workload VM