Persistent TLS handshake timeout to Fastly CDN range 151.101.0.0/16 (affects cdn.pubnub.com and possibly other Fastly-hosted sites)

Router: OPNsense 26.1.11_6-amd64 (customer-owned), WAN on DHCP

Summary

Outbound HTTPS connections from my network to specific Fastly CDN IPs (151.101.0.143, 151.101.64.143, 151.101.128.143, 151.101.192.143 — the anycast addresses behind cdn.pubnub.com, CNAME b.ssl.global.fastly.net) complete the TCP handshake but then hang indefinitely at the TLS handshake stage: the ClientHello is sent and no ServerHello is ever returned. The connection eventually times out client-side (15-20s). This happens consistently and is reproducible on demand.

This is not a problem with my router, firewall, or any device — see diagnostic steps below. It appears to be a routing or peering issue between your network and Fastly for this specific IP range.

Impact

Any site or service that loads a resource from this Fastly range over IPv4 hangs or fails to fully load. Specifically identified via zillow.com, which loads a script from cdn.pubnub.com and hangs waiting on it.

Diagnostic steps already completed

Reproduced with curl directly (bypassing all browsers), confirming it's not application-specific:

curl -v --max-time 20 https://cdn.pubnub.com/pubnub-7.5.0.min.js -o /dev/null

Result: DNS resolves correctly to the four IPs above. TCP connects ("Connected to cdn.pubnub.com... port 443"). TLS ClientHello is sent. No response. Times out after the configured max-time with no TLS handshake completion and no RST.

Ruled out local firewall: checked OPNsense's live firewall log filtered on destination port 443 and each of the four destination IPs during a reproduction — action logged is pass, not block/reject. The firewall is not the source of the drop.

Ruled out MTU/fragmentation: repeated the test forcing TLS 1.2, HTTP/1.1, and a single cipher suite to minimize the ClientHello size (224 bytes vs. the default 319 bytes). Identical hang. Packet size is not the trigger.

Ruled out request fingerprinting/WAF filtering: repeated the test with a realistic browser User-Agent and Referer header matching normal browser traffic. Identical hang.

Ruled out local device/OS/browser configuration: tested across two different browsers (Safari and Chrome) and raw curl, all failing identically on this network. No VPN, proxy, or MDM profile is configured on the affected machine.

Confirmed it is network-path-specific, not destination-side: the identical curl request, run from the same machine on a cellular hotspot (different ISP/ASN entirely), completed successfully in under a second — full TLS handshake, valid certificate (CN=*.pubnub.com), and a normal HTTP response. That request was routed via IPv6 to a different Fastly PoP (2607:7700:...), which is unavailable from this network (no IPv6 to Fastly here).

Confirmed persistence across a new public IP: released and renewed the OPNsense WAN DHCP lease. Same public-facing behavior, same destination IPs, identical hang afterward — this is not tied to a single leased IP.

Request

Please investigate routing/peering from your network to Fastly's 151.101.0.0/16 anycast range (at minimum the four IPs listed above) for my account/circuit, and escalate to your network engineering or peering team if needed. Happy to provide packet captures or run additional tests on request.