Summary
Behind zero-trust corporate VPNs (aTrust / EasyConnect class) that map external domains into 198.18.0.0/15, the egress guard blocks every provider request before it leaves the process, and the error carries no clue: the whole OAuth exchange fails in ~36 ms with only
{"error":{"code":"oauth_token_exchange_failed","message":"OAuth token request failed."}}No status, no resolved address, no hostname. The sub-round-trip latency is the only tell.
Credit: found and diagnosed by @Userneima while field-testing the Feishu source pack — full report with the working patch shapes in SkardiLabs/skardi#186 (comment). Filing so it doesn't get lost; they offered to open the fix PR themselves.
Three verified facts (against current main)
isBlockedIpv4 checks reservedIpv4Cidrs unconditionally (src/core/request.ts): allowPrivateNetwork only opens the private CIDR list, so a host that resolves into a reserved range (198.18.0.0/15 is benchmarking space, which zero-trust VPNs repurpose) cannot be allowed by any existing switch. In the report, open.feishu.cn resolved to 198.18.0.196.- The guard error names neither the address nor the escape hatch (
src/core/guarded-fetch.ts): "<field> must not resolve to private or reserved IP addresses" — the operator cannot tell WHICH address tripped it, or that a VPN is rewriting DNS.
providerFetch is constructed without allowPrivateNetwork at all (src/providers/provider-runtime.ts: export const providerFetch: ProviderFetch = createProviderFetch();) — so OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK never reaches provider egress, even for the private ranges it is supposed to open. Possibly intended for defense-in-depth, but worth an explicit statement either way.
Suggested fix (two independent parts, both prototyped in the report)
- Diagnosable error: include the resolved address and the remediation pointer in the guard error, e.g.
... (resolved 198.18.0.196; if this host is reached through a corporate VPN that uses a reserved range, add it to OOMOL_CONNECT_EGRESS_SKIP_IP_CHECK_HOSTS).
- Deployment-level hostname allowlist (
OOMOL_CONNECT_EGRESS_SKIP_IP_CHECK_HOSTS, exact host or .suffix match) that skips only the IP-range check for the listed hosts, leaving scheme/port/redirect/response-size guards untouched. The reporter ran the full Feishu OAuth flow successfully with =".feishu.cn,.larksuite.com" on a local build.
Related context: this is the deployment-environment sibling of #267 (both are "the gateway works, but a real corporate environment can't get through the front door with no actionable error").
Summary
Behind zero-trust corporate VPNs (aTrust / EasyConnect class) that map external domains into
198.18.0.0/15, the egress guard blocks every provider request before it leaves the process, and the error carries no clue: the whole OAuth exchange fails in ~36 ms with only{"error":{"code":"oauth_token_exchange_failed","message":"OAuth token request failed."}}No status, no resolved address, no hostname. The sub-round-trip latency is the only tell.
Credit: found and diagnosed by @Userneima while field-testing the Feishu source pack — full report with the working patch shapes in SkardiLabs/skardi#186 (comment). Filing so it doesn't get lost; they offered to open the fix PR themselves.
Three verified facts (against current
main)isBlockedIpv4checksreservedIpv4Cidrsunconditionally (src/core/request.ts):allowPrivateNetworkonly opens the private CIDR list, so a host that resolves into a reserved range (198.18.0.0/15is benchmarking space, which zero-trust VPNs repurpose) cannot be allowed by any existing switch. In the report,open.feishu.cnresolved to198.18.0.196.src/core/guarded-fetch.ts):"<field> must not resolve to private or reserved IP addresses"— the operator cannot tell WHICH address tripped it, or that a VPN is rewriting DNS.providerFetchis constructed withoutallowPrivateNetworkat all (src/providers/provider-runtime.ts:export const providerFetch: ProviderFetch = createProviderFetch();) — soOOMOL_CONNECT_ALLOW_PRIVATE_NETWORKnever reaches provider egress, even for the private ranges it is supposed to open. Possibly intended for defense-in-depth, but worth an explicit statement either way.Suggested fix (two independent parts, both prototyped in the report)
... (resolved 198.18.0.196; if this host is reached through a corporate VPN that uses a reserved range, add it to OOMOL_CONNECT_EGRESS_SKIP_IP_CHECK_HOSTS).OOMOL_CONNECT_EGRESS_SKIP_IP_CHECK_HOSTS, exact host or.suffixmatch) that skips only the IP-range check for the listed hosts, leaving scheme/port/redirect/response-size guards untouched. The reporter ran the full Feishu OAuth flow successfully with=".feishu.cn,.larksuite.com"on a local build.Related context: this is the deployment-environment sibling of #267 (both are "the gateway works, but a real corporate environment can't get through the front door with no actionable error").