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, setting up a "pass out on WAN from LAN to any port 443 synproxy state" rule did work around the problem.)
  B) Disable scrubbing

I'm seeing the same issue. My workaround is to run a SOCKS proxy on the firewall itself and connect through that, but that's a hack.

With a mirror, a three-way mirror almost makes more sense than a hot spare. Hot spares are more useful for RAIDZ/RAIDZ2.

I have an OPNsense firewall set up, no proxy, no ZenArmor, just NAT. It's in a double-NAT config, which is temporary, but right now websites that fetch resources from s3.amazonaws.com fail to load those resources. I can resolve that name just fine, I can make a TCP connection to it, but the TLS handshake times out. It's not breaking anywhere else. See a transcript of a wget attempt on one such resource -

Code Select Expand

wget -vd https://s3.amazonaws.com/shirtpocket/SuperDuper/SuperDuper\!.dmg
DEBUG output created by Wget 1.25.0 on darwin24.1.0.

Reading HSTS entries from /Users/jade/.wget-hsts
URI encoding = 'UTF-8'
Converted file name 'SuperDuper!.dmg' (UTF-8) -> 'SuperDuper!.dmg' (UTF-8)
--2025-09-17 08:39:21--  https://s3.amazonaws.com/shirtpocket/SuperDuper/SuperDuper!.dmg
Resolving s3.amazonaws.com (s3.amazonaws.com)... 16.15.216.57, 54.231.172.112, 52.217.174.80, ...
Caching s3.amazonaws.com => 16.15.216.57 54.231.172.112 52.217.174.80 52.217.170.152 52.217.87.182 52.217.173.200 52.216.212.40 52.217.126.112
Connecting to s3.amazonaws.com (s3.amazonaws.com)|16.15.216.57|:443... connected.
Created socket 6.
Releasing 0x000060000203c2e0 (new refcount 1).
Initiating SSL handshake.
SSL handshake timed out.
Closed fd 6
Unable to establish SSL connection.
Where should I be looking next? I've monkeyed with MTU/MSS to no avail, and I don't have anything set up that should be trying to perform a MITM or anything like that. (Pretty much all other HTTPS/TLS destinations work just fine, including DNS over TLS). I'm betting the issue has something to do with double-NAT, but I'm not sure what or where.

UPDATE: I still don't know what's causing this, but I have a temporary workaround. I've got a machine that's dual-homed on both networks (the one inside the OPNsense firewall, and the one between it and the other router), and I set up a proxy on that. The "broken" URLs work through the proxy. This pretty well confirms that the double-NAT is somehow breaking things, but I'll be pickl't if I know how.