A severe issue plagued Google Kubernetes Engine (GKE) clusters in europe-west, causing intermittent API server connection timeouts for pods. This problem, which emerged in January 2026, affected hundreds of developers and brought production deployments to a standstill. Initial investigations ruled out customer-side changes and common network issues like conntrack exhaustion. The complexity grew as the problem impacted multiple GKE clusters and even external client connections, pointing to a systemic issue.Packet captures revealed that synchronous packets from pods were reaching the control plane VMs, but instead of a SYN-ACK, an out-of-place ACK was being returned. This indicated a problem with TCP connection state management on the control plane nodes. Simultaneously, metrics for Private Service Connect showed a sharp increase in "Proxy protocol drop: invalid ACK packet" coinciding with a software version rollout. This USPS change, intended to fix a security vulnerability, was inadvertently dropping challenge ACKs.Challenge ACKs, defined by RFC 5961, are a security mechanism where a server sends an ACK to verify the legitimacy of a new connection attempt using a previously used port after an old connection has closed. The USPS change incorrectly classified these legitimate challenge ACKs as invalid, causing them to be dropped silently. This behavior was exacerbated in GKE clusters using Private Service Connect due to its NAT layer, which frequently caused port reuse and thus triggered challenge ACKs more often.A temporary mitigation involved rolling back the USPS change, which immediately resolved the "invalid ACK packet" drops and restored connectivity for the affected GKE clusters. However, this rollback was merely a band-aid, as it did not address the root cause of why the control plane VMs were holding onto connections in a FIN_WAIT_2 state for an unusually long time. This persistent long-held connection state was the underlying issue that created the conditions for the challenge ACK problem. The investigation then delved deeper to uncover the remaining bugs responsible for this prolonged connection state.