Cloudflare tunnels inoperative in Russia

Zero Trust Cloudflare Tunnel
1

What is the name of the domain?

Private and irrelevant

What is the error number?

1033, 502, Timeout

What is the error message?

Connection terminated error=“failed to dial to edge with quic: timeout: no recent network activity” connIndex=2; Failed to serve tunnel connection error=“timeout: no recent network activity”

What is the issue you’re encountering

Recently Tunnels became entirely inoprtative in Russia. I have a server there that I use Tunnels to access. I found a very small group of other people with the same issue on Russian censorship circumvention forums; presumably Tunnels are not that popular. This started happening at the beginning of the month, and slowly got worse and worse until it could simply not connect anymore.

What steps have you taken to resolve the issue?

Checked network and internet access, used a different server, attempted to use censorship circumvision and general availability transparent proxies.

What are the steps to reproduce the issue?

  • Be in Russia
  • Attempt to use Cloudflare Tunnels normally (following the start tutorial will be enough)
  • Verified on Windows and Ubuntu 22.04 LTS
1 Like
2

HTTP/2 Logs, Tunnel errors (1033), no further messages:


апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF GOOS: linux, GOVersion: go1.22.10, GoArch: amd64
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Settings: map[no-autoupdate:true p:http2 protocol:http2 token:*****]
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Generated Connector ID: [snip]
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Initial protocol http2
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use 192.168.1.5 as source for IPv4
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use [snip] in zone enp4s0 as source for IPv6
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use 192.168.1.5 as source for IPv4
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use [snip] in zone enp4s0 as source for IPv6
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Starting metrics server on 127.0.0.1:20241/metrics
~

QUIC Logs, 502s with the Cloudflare plug (although I also experienced timeouts and 1033s, it is inconsistent, presumably due to it restarting infinitely). Logs repeating cyclically:

апр 25 10:58:31 server cloudflared[798455]: 2025-04-25T05:58:31Z INF Registered tunnel connection connIndex=1 connection=[snip] event=0 ip=198.41.192.37 location=led01 protocol=quic
апр 25 10:58:32 server cloudflared[798455]: 2025-04-25T05:58:32Z INF Using [CurveID(4588) CurveID(25497) CurveP256] as curve preferences connIndex=2 event=0 ip=198.41.192.77
апр 25 10:58:33 server cloudflared[798455]: 2025-04-25T05:58:33Z INF Using [CurveID(4588) CurveID(25497) CurveP256] as curve preferences connIndex=3 event=0 ip=198.41.200.63
апр 25 10:58:36 server cloudflared[798455]: 2025-04-25T05:58:36Z WRN Failed to serve tunnel connection error="timeout: no recent network activity" connIndex=0 event=0 ip=198.41.200.73
апр 25 10:58:36 server cloudflared[798455]: 2025-04-25T05:58:36Z WRN Serve tunnel error error="timeout: no recent network activity" connIndex=0 event=0 ip=198.41.200.73
апр 25 10:58:37 server cloudflared[798455]: 2025-04-25T05:58:37Z ERR Failed to serve tunnel connection error="context canceled" connIndex=2 event=0 ip=198.41.192.77

This issue is critical and impacts an entire product across an entire region.

4

Same here!
Cloudflare Tunnel was working fine untill the start of april. Now I cant access my homelab from outside my private network.

Tried reinstalling cloudflared as docker container and systemd, didn’t help either. So it might be a issue with the ISP and their firewall?

I am getting this error when launching cloudflared:

2025-04-26T06:58:26Z INF Starting tunnel tunnelID=b1929b96-0fed-47ee-80cf-db78173c7b16
2025-04-26T06:58:26Z INF Version 2025.4.0 (Checksum df13e7e0a027f648c410b5cc701fbcff028724d0e93209796cdbb79ec38695d4)
2025-04-26T06:58:26Z INF GOOS: linux, GOVersion: go1.22.10, GoArch: amd64
2025-04-26T06:58:26Z INF Environmental variables map[TUNNEL_TOKEN:*****]
2025-04-26T06:58:26Z INF Generated Connector ID: f21c176e-8db7-4e6b-adab-8b282c7104d4
2025-04-26T06:58:26Z INF cloudflared will not automatically update if installed by a package manager.
2025-04-26T06:58:26Z INF Initial protocol quic
2025-04-26T06:58:26Z INF ICMP proxy will use 192.168.0.101 as source for IPv4
2025-04-26T06:58:26Z INF ICMP proxy will use fe80::8647:9ff:fe34:b841 in zone enp1s0 as source for IPv6
2025-04-26T06:58:26Z INF ICMP proxy will use 192.168.0.101 as source for IPv4
2025-04-26T06:58:26Z INF ICMP proxy will use fe80::8647:9ff:fe34:b841 in zone enp1s0 as source for IPv6
2025-04-26T06:58:26Z INF Starting metrics server on 127.0.0.1:20241/metrics
2025-04-26T06:58:26Z INF Using [CurveID(4588) CurveID(25497) CurveP256] as curve preferences connIndex=0 event=0 ip=198.41.192.7
2025-04-26T06:58:31Z ERR Failed to serve tunnel connection error="context canceled" connIndex=0 event=0 ip=198.41.192.7
2025-04-26T06:58:31Z INF Retrying connection in up to 2s connIndex=0 event=0 ip=198.41.192.7
2025-04-26T06:58:32Z INF Tunnel server stopped
2025-04-26T06:58:32Z ERR Initiating shutdown error="context canceled"
2025-04-26T06:58:32Z ERR icmp router terminated error="context canceled"
2025-04-26T06:58:32Z INF Metrics server stopped

And this with --protocol http2 flag enabled:

2025-04-26T06:58:58Z INF Starting tunnel tunnelID=b1929b96-0fed-47ee-80cf-db78173c7b16
2025-04-26T06:58:58Z INF Version 2025.4.0 (Checksum df13e7e0a027f648c410b5cc701fbcff028724d0e93209796cdbb79ec38695d4)
2025-04-26T06:58:58Z INF GOOS: linux, GOVersion: go1.22.10, GoArch: amd64
2025-04-26T06:58:58Z INF Settings: map[p:http2 protocol:http2]
2025-04-26T06:58:58Z INF Environmental variables map[TUNNEL_TOKEN:*****]
2025-04-26T06:58:58Z INF Generated Connector ID: 2fdeaa29-ee1f-4318-b736-8891251d90ff
2025-04-26T06:58:58Z INF cloudflared will not automatically update if installed by a package manager.
2025-04-26T06:58:58Z INF Initial protocol http2
2025-04-26T06:58:58Z INF ICMP proxy will use 192.168.0.101 as source for IPv4
2025-04-26T06:58:58Z INF ICMP proxy will use fe80::8647:9ff:fe34:b841 in zone enp1s0 as source for IPv6
2025-04-26T06:58:58Z INF ICMP proxy will use 192.168.0.101 as source for IPv4
2025-04-26T06:58:58Z INF ICMP proxy will use fe80::8647:9ff:fe34:b841 in zone enp1s0 as source for IPv6
2025-04-26T06:58:58Z INF Starting metrics server on 127.0.0.1:20241/metrics

Even if it seems to be okay with http2 protocol turned on, it isn’t.
Cloudflare says it’s degraded and I get 502 The origin has been unregistered from Argo Tunnel error when trying to access my webpage.

5

I made a GitHub issue for this too:

6

Have you tried switching to http2 protocol instead? :thinking:
Might be your ISP might not support Quic protocol. Could you select other protocol e.g. http2, using the command and retry again as follows on the instructions from below article? :thinking:

Furthermore, might be ISP filter or Country is blocking Cloudflare IP as well :thinking:

502 error you’re experiencing is usually an issue at the origin host:

Is your Website running fine over HTTPS (bound to the port 443) and with a valid SSL certificate at the origin host/server or rather not?

If so, then noTLSVerify option should be enabled from the Zero Trust dashboard for your tunnel public hostname.

7

This is not useful, I’m sorry. Please read my post carefully - I’ve already made these observations and tried http2.

This is an issue with the country indeed, Russia is blocking Cloudflare IPs but only to an extent. Please read.

8

Might be you’re out of luck here then. Sorry to hear this.

Thank you for feedback in the meantime.

1 Like
9

Hello. I do also experience same issue. I did basic tcp connection test using curl and it passes. I can connect to cloudflare IP, that means IPS is not blocking connection

# curl -v http://198.41.200.233
*   Trying 198.41.200.233:80...
* Connected to 198.41.200.233 (198.41.200.233) port 80 (#0)
> GET / HTTP/1.1
> Host: 198.41.200.233
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Date: Tue, 29 Apr 2025 16:55:24 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 16
< Connection: close
< X-Frame-Options: SAMEORIGIN
< Referrer-Policy: same-origin
< Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Expires: Thu, 01 Jan 1970 00:00:01 GMT
< Server: cloudflare
< CF-RAY: 938053aacda29da6-DME
< 
* Closing connection 0
10

This issue is related to testing the blocking of foreign providers. The tests were conducted in various regions of Russia, except for Moscow and Saint Petersburg.

What wasn’t working? HTTP traffic did not work, while any other TCP protocol, such as RDP and SSH, functioned normally.

11

The project zapret seems to remedy this. Leads me to the conclusion that this is definitively government interference.

ISPs may be specifically blocking Cloudflare Tunnel (usually port 7844) even if plain TCP works. The default zapret configuration does not handle this, so some minor extra configuration is needed (this is based on the standard zapret configuration):

  1. In /opt/zapret/config or your config file, change the ports and add 7844 for both protocols:

    NFQWS_PORTS_TCP=80,443,7844
NFQWS_PORTS_UDP=443,7844

  2. Add the same ports in NFQWS_OPT accordingly:

    NFQWS_OPT="\
--filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-split-pos=method+2 --dpi-desync-fooling=md5sig <HOSTLIST> --new \
--filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-fooling=badseq,md5sig <HOSTLIST> --new \
--filter-tcp=7844 --dpi-desync=fake,disorder --dpi-desync-fooling=md5sig <HOSTLIST> --new \
--filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 <HOSTLIST_NOAUTO> --new \
--filter-udp=7844 --dpi-desync=fake --dpi-desync-repeats=6 <HOSTLIST_NOAUTO>"

  3. Restart zapret:

    sudo systemctl restart zapret

After that, cloudflared tunnel run ... works, more or less. There are some errors, but the main functionality is working and it doesn’t drop any connections.

It’s necessary to specify --protocol http2 in the tunnel service args; QUIC doesn’t work here at all.

1 Like
12

This topic was automatically closed after 15 days. New replies are no longer allowed.