Some Chinese sites not returning packets when accessed via OPNsense [WAN].

[EricPerl]

During the 2nd part, the machine (same IP as in part 1) was added to the alias containing hosts that are directed to your external WGD VPN provider?
Apart from validating that this machine can access that site, I'm not sure what I can do with that.
It would have been more straightforward to connect that machine to your edge router (bypassing OPN).

The capture from part 1 indicates a complete connectivity failure. That connection attempt is either outright blocked, or maybe it gets routed into a void.
I can't reconcile this with the previous capture (reply #8) on WAN.
The WAN side indicated several roundtrips to the target website (3-way handshake, client then server hello, key exchange and a HTTPS roundtrip, connection close).

I don't really care to see the DNS lookups. We know the IP by now.
In an attempt to connect the dots, for the part 1 use case (not going thru the VPN provider), please provide a WAN and LAN capture filtered to the target IP for that curl command.

[raybies]

Can you pls give me a full list of tests you would like me to perform, how you would like them filtered and the expected format?

[EricPerl]

One packet capture on OPN, with WAN and LAN selected, filtered by target 'host address' IP.
While that's going on, a single curl invocation. Then download the capture (it should contain 2 cap files and a json).
It's similar to what you did in reply #8, apart from the fact that we'd see both interfaces for the exact same exchange, not just WAN.
The filtering is for your privacy and reduces the size of the file. We don't need to see other traffic.

Again, the capture is #8 looked normal to me, but it makes no sense when compared with the Wireshark cap on the host.
Having the LAN side too, for a single exchange, would eliminate discrepancies due to looking at discrete exchanges that may have happened in different conditions.