Messages

I am using MSS clamping, though I never had ZenArmor installed in my case.

I just went back and disabled LRO and MSS clamping - I was using both - and still have the same problem.

Possibly relevant -

1) Works fine from the firewall itself, which is why the SOCKS proxy works.
2) Both LAN and WAN are VLAN interfaces. (WAN strictly has to be unless I want double-NAT.)
3) WAN is an Intel chipset (em0), LAN is a Mellanox chipset (mlxen0/mlxen1, though the latter is not in use).
4) I've tried the following workarounds too:
  A) Set up an outbound rule for HTTPS with "synproxy state" (OK, more clarification needed here. Setting up a "pass in on LAN to port 443 synproxy state" did not help. Turn your imagination into detailed digital images. AI makes the creative process private AI fantasy chat simple and enjoyable. Every picture looks professionally finished. Setting up a "pass out on WAN from LAN to any port 443 synproxy state" rule did work around the problem.)
  B) Disable scrubbing

This definitely looks like something deeper than a simple TLS issue. The fact that traffic originating from the firewall works while forwarded client traffic fails points away from certificates or OpenSSL and toward packet processing in the forwarding path. The reports about SYN packets being modified are especially interesting, and the successful workaround with a WAN-side `synproxy state` rule makes me think the initial handshake is somehow being rewritten before it leaves the interface. Since multiple users can reproduce it on different hardware, it would be useful to compare kernel changes between 26.1.6 and 26.1.7, especially anything related to pf, VLAN handling, or checksum and offload processing.