**Environment:**
- OPNsense 25.7.11_9-amd64
- Running as a VM on Proxmox (tested on both VirtIO and Intel E1000 emulated NICs — same result on both)
- WAN: DHCP, no PPPoE, no VLAN tagging
- Outbound NAT: Hybrid mode
**Symptom:**
TCP connections from LAN/WiFi clients (NAT'd through WAN) to certain destinations (confirmed with `www.usmagazine.com` test site, 192.0.66.2:443) hang indefinitely — SYN is sent, no SYN-ACK or any reply ever received. Other destinations (e.g. google.com) work fine through the same forwarding path.
Packet capture on WAN (and confirmed at the Proxmox host bridge level, before the physical NIC) shows the outbound SYN for the affected destination is malformed:
```
16:47:15.153180 IP <wan-ip>.11293 > 192.0.66.2.443: Flags , seq 64240, win 0, length 0
```
No TCP options at all (no MSS, window scale, SACK-permitted, or timestamps), and window size of 0 — not a normal SYN from any TCP stack.
**Critically:** `curl -v 192.0.66.2.443` run *from the OPNsense shell itself* to the same destination completes a normal handshake with correct options and a real window size every time. Only traffic that is **forwarded/NAT'd** through the box (from LAN or WiFi clients) produces the malformed SYN. This is 100% reproducible.
**Ruled out so far:**
- Hardware checksum/TSO/LRO offload — disabled via GUI and via `ifconfig -tso4 -tso6 -rxcsum -txcsum -lro` directly on all interfaces — no change
- `net.inet.tcp.tso=0` system tunable — no change (also confirmed default is TSO enabled and restored correctly)
- Firewall → Settings → Normalization → Disable interface scrub — no change
- Multiqueue on the VirtIO NICs (was set to 8, cleared to default) — no change
- NIC model — reproduced identically on both VirtIO and Intel E1000 emulated NICs
- Zenarmor/Sensei (os-sunnyvalley) — was installed, fully uninstalled + VM rebooted — no change
- Outbound NAT — Hybrid mode, WAN IP is correctly translated (confirmed in state table, `SYN_SENT:CLOSED`)
**Also confirmed:**
- The exact same public IP works fine when tested with a laptop directly connected (bypassing OPNsense entirely) — rules out ISP/destination-side IP blocking
- A separate **bare-metal** OPNsense install (same version) on a different machine, same general network type, does not reproduce this issue
- Works fine over a completely separate network path (cellular)
This strongly points at something in the pf forwarding/NAT code path specifically stripping TCP options and zeroing the window on certain outbound SYNs, independent of any NIC/driver/offload layer. Happy to provide additional packet captures, `pfctl -vvsr` output, states output, or test further changes — just let me know what's useful.