[CF1] tunnel connectivity troubleshooting guide #26582
Conversation
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
| Key points: | ||
|
|
||
| - Cloudflare Tunnel requires outbound connectivity to `region1.v2.argotunnel.com` and `region2.v2.argotunnel.com` (or to the equivalent `us-region1` and `us-region2` endpoints when using the US region). | ||
| - For basic connectivity, `cloudflared` only needs **one reachable IP in one region**. |
There was a problem hiding this comment.
I don't think we want to say it like this, even though it is true. We need customers to benefit from high availability and built-in resilience of the product.
So for the purpose of the troubleshooting guide customers can test against one IP in one region, but to have a setup that is working, resilient and supported by us, they must ensure cloudflared connectivity to both regions.
There was a problem hiding this comment.
@nikitacano agreed, this was just notes leftover from our meeting, not final draft content
|
|
||
| Cloudflare Tunnel requires outbound connectivity to `region1.v2.argotunnel.com` and `region2.v2.argotunnel.com` (or to the equivalent `us-region1` and `us-region2` endpoints when using only the US region). | ||
|
|
||
| For basic connectivity, `cloudflared` only needs one reachable IP in one region. For high availability and [four active replicas](/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/), Cloudflare recommends allowing connectivity to both regions (that is, both `region1.v2.argotunnel.com` and `region2.v2.argotunnel.com` or both `us-region1` and `us-region2`). |
There was a problem hiding this comment.
Same here: we absolutely require customers to have connectivity to both regions in order to consider their deployment supported.
|
@nikitacano updated the PR with a full first draft. added questions for you marked as (question) within the doc. |
| To resolve: | ||
|
|
||
| - Configure the host machine to use `1.1.1.1` as its resolver. | ||
| - If you must keep using your existing resolver, (question) then what? |
There was a problem hiding this comment.
Then investigate with your system administrator and / or ISP provider why your local resolver is returning a different response. Recursive DNS resolvers should return the same response as the authoritative DNS server since the authoritative server is always the source of truth where each hostname should point to.
|
|
||
| To resolve: | ||
|
|
||
| - Check for firewall rules blocking (question) what? 1.1.1.1.? Endpoints? ports? |
There was a problem hiding this comment.
... blocking DNS traffic altogether (UDP on port 53) or specific DNS queries related to Cloudflare.
|
|
||
| You have already confirmed DNS is working in the previous steps. These connectivity tests now verify whether your environment allows traffic to Cloudflare on port `7844`. By default, `cloudflared` automatically falls back to whichever protocol is available. | ||
|
|
||
| If a protocol is blocked but you force `cloudflared` to use it (for example, forcing QUIC when UDP is blocked), the tunnel will fail to connect. |
There was a problem hiding this comment.
|
|
||
| `cloudflared` will only be able to connect using `quic`. If you force `http2` in your configuration while TCP is blocked, the tunnel will fail. | ||
|
|
||
| To resolve: (question) |
There was a problem hiding this comment.
Either allow TCP on your local network firewall on port 7844 or stop forcing http2 to allow cloudflared to connect over QUIC instead.
|
|
||
| `cloudflared` will only be able to connect using `http2`. If you force `quic` while UDP is blocked, the tunnel will fail. | ||
|
|
||
| To resolve: (question) |
There was a problem hiding this comment.
Either allow UDP on local network firewall on port 7844 or stop forcing QUIC to allow cloudflared to connect over HTTP/2 instead.
|
|
||
| This usually indicates a firewall policy or upstream security control that does not allow outbound traffic (or return traffic) on port `7844`. | ||
|
|
||
| To resolve: (question) |
There was a problem hiding this comment.
Allow all traffic over port 7844 on local network firewall and, if that doesn't help, troubleshoot this with your ISP or service provider.
|
|
||
| To resolve: (question) | ||
|
|
||
| ### 3.4 Troubleshooting results |
There was a problem hiding this comment.
This section is good, however customer will not narrow down whether they are using stateful vs stateless firewall without taking packet captures of their traffic on the host machine. Unfortunately, netcat (nc) output will be the same in both situations. Thus, I wonder if this is too advanced for a generic user and as such we could leave it out since stateless firewalls are quite uncommon these days.
3 participants
Summary
Screenshots (optional)
Documentation checklist