:bug: Firewalled/proxy environment difficulties

[tjb900]

Describe the bug

We have an environment where outbound access is firewalled and HTTP(s) access goes through a proxy. After following the (disappointing, but somewhat understandble) discussions on this topic in e.g. #350, I requested exemptions as per the document here:

https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall/

However, it appears these are still insufficient - a hello world test still doesn't work.

To Reproduce Steps to reproduce the behavior:

# https_proxy=redacted ./cloudflared-linux-amd64 tunnel --hello-world
2024-05-06T02:42:28Z INF Thank you for trying Cloudflare Tunnel. Doing so, without a Cloudflare account, is a quick way to experiment and try it out. However, be aware that these account-less Tunnels have no uptime guarantee. If you intend to use Tunnels in production you should use a pre-created named tunnel by following: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps
2024-05-06T02:42:28Z INF Requesting new quick Tunnel on trycloudflare.com...
... hangs ...

And using strace I can see it is trying to connect directly to api.trycloudflare.com, not using a proxy:

[pid 29248] connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.16.231.132")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 29249] connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.16.230.132")}, 16) = -1 EINPROGRESS (Operation now in progress)

Expected behavior

I'd really have hoped the conventional HTTP(S) API calls required to setup the tunnels should be able to be made through a proxy. I've seen justifications elsewhere for the tunnel itself to not support proxied operation due to a preference for QUIC, and while that's disappointing it's at least understandable from a technical standpoint. The non-tunnel setup operations should still be proxyable though.

The page above listing required firewall exemptions potentially also needs amending to list api.trycloudflare.com for quick tunnels.

Environment and versions

• OS: Linux
• Architecture: AMD64
• Version: 2024.4.1

Logs and errors

See above.

Additional context Add any other context about the problem here.

[tjb900]

Aha! I think this is related to this:

        client := http.Client{
                Transport: &http.Transport{
                        TLSHandshakeTimeout:   httpTimeout,
                        ResponseHeaderTimeout: httpTimeout,
                },
                Timeout: httpTimeout,
        }

Creating blank http.Transport seems to be considered dangerous, see also:

https://github.com/kubernetes-retired/go-open-service-broker-client/issues/132 https://github.com/mozilla-services/aws-signing-proxy/pull/4

I have a patch which uses DefaultTransport.Clone() and then makes the required changes instead of starting with a blank Transport, happy to put up for PR if it would be welcome!

[ChaiByte]

I'd really have hoped the conventional HTTP(S) API calls required to setup the tunnels should be able to be made through a proxy

Try https://github.com/ChaiByte/CF-Tunnel-Transparent-Proxy/