26.7.7: Lark HTTPS connections time out after upgrade; hotspot works

[Brilliant Technologies Lt]

Hello,

After upgrading OPNsense to 26.7.7, several Lark (larksuite.com) features stopped loading, including Reports and Approvals. They worked before the upgrade. The same Mac and account work on a mobile hotspot but fail through the usual OPNsense network. The root cause has not been established.

Symptoms:
- https://oa.larksuite.com/report/record/entry stays blank and eventually reports a page error. Other Lark features are also affected.
- DNS lookup returns an Akamai CNAME chain and 95.100.110.24 / 95.100.110.20.
- curl -vI --connect-timeout 10 --max-time 20 https://oa.larksuite.com/ resolves both IPv4 addresses, attempts TCP/443 on each, then times out with error 28 before any TLS handshake. No IPv6 address was returned in this curl test.
- No VPN/proxy is enabled on the client. nslookup shows a loopback DNS resolver (127.0.2.2); its providing software has not been identified.

Checks attempted:
- Default IPv4/IPv6 allow rules from LAN network to any are present. Exact LAN subnet membership and routing/NAT topology still need verification.
- Added a temporary TCP/443 pass rule for the affected client to both destination IPs: no improvement.
- Temporarily disabling Suricata was attempted without improvement; independent confirmation that the service fully stopped is not available.
- Rebooted OPNsense: no improvement.
- A packet capture attempt yielded no usable capture, so WAN transmission and return traffic are not yet verified.

Logs:
Live View showed TCP/443 from the affected client to 95.100.110.24 blocked under 'Default deny / state violation rule'. TCP flags and exact correlation with a fresh connection attempt were not captured. Kernel logs also show 'pf: BAD state' and 'pf: loose state match' involving other clients; these are not proven related to this client's Lark failure.

Are there known 26.7.7 PF state, interface, NAT, or forwarding changes matching these symptoms? What minimal diagnostics can distinguish local PF/NAT/routing trouble from upstream connectivity trouble? If this matches a known regression, is there an officially recommended fix or targeted rollback?

The previous working version, full current build suffix, hardware/NIC details, and full topology have not yet been collected and can be supplied if required.

Thank you.

[pfry]

[...]Live View showed TCP/443 from the affected client to 95.100.110.24 blocked under 'Default deny / state violation rule'. TCP flags and exact correlation with a fresh connection attempt were not captured. Kernel logs also show 'pf: BAD state' and 'pf: loose state match' involving other clients; these are not proven related to this client's Lark failure.[...]

Looks like a failed session setup, i.e. no state = timeout. I'd start with the info (specifically TCP flags) from that state violation - it's easiest to view from the "i" in the Live View; it's also in the session log. A loose match may be normal (it's the default); state mismatches can stem from path inconsistencies (bypassing the firewall). Given the loose state default, bypassing the expected interface is generally less of an issue.