Forged TCP RST (TTL 128) killing frontend sessions on ProxySQL 6033 — PXC 8.4.10 / ProxySQL 3.0.9

Polyglot Projects ProxySQL
1

Environment

  • ProxySQL 3.0.9, two nodes (keepalived VIP 10.160.9.72:6033)
  • Percona XtraDB Cluster 8.4.10, 3 nodes, singlewrite (HG10 writer / 11 reader)
  • Zabbix 7.0.19 frontend (PHP), Oracle Linux 9

Symptom
Linking an MSSQL template from the Zabbix frontend fails with MySQL server has gone away. Simple templates work. Only through ProxySQL.

What the packet captures show
Simultaneous tcpdump on both ends:

  • A single TCP RST arrives inbound on both hosts, 657 µs apart, in the same session
  • Both carry TTL 128 — Linux stacks here use 64
  • Neither host transmits any RST
  • The reset lands ~159 µs after a 1242-byte INSERT INTO item_rtname ... UPPER('Service\'s TCP port state')
  • The statement never reaches the PXC backend

Ruled out

  • Replaying the exact bytes from the pcap via the mysql CLI succeeds (returns Duplicate entry — so it reaches the server)
  • Payloads up to 4 MB pass fine; the 1.2 KB one that fails does not
  • SQLi-like patterns (UNION SELECT, @@version, xp_cmdshell, backslash-escaped quotes) all pass in isolation
  • Protocol is plain COM_QUERY (mysql.command = 3), no binary prepared statements
  • sql_mode, server_version, charset identical across nodes and through ProxySQL
  • ProxySQL automatic_detect_sqli and firewall both disabled; query rules are SELECT split only
  • ProxySQL timeouts and packet size settings excluded

Not reporting this as a ProxySQL bug — the captures rule that out. Looking for anyone who has seen 6033 caught by MySQL application-type inspection rules, and what they did about it.

Thanks in advance

Stefano

1 Like