You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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!
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:
And using strace I can see it is trying to connect directly to
api.trycloudflare.com
, not using a proxy: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
Logs and errors
See above.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: