So, Russia began blocking Webtunnel bridges, which is good actually

The goods news is that:

  • It’s not IP blocks anymore, like it was the case with obfs4, so it’s less collateral damage and censor is satisfied and eager to report his quota

  • Replacing domains is cheap for relay operator, .xyz domain was like, what? $1 a pop?

  • It’s not the end of life for your bridge as after Youtube got blocked, the general population began using programs like Zapret, and since it’s not IP block, getting past SNI block is trivial, so you may still see traffic continue to grow

In a way, the blocking is much less harsher than obfs4 was getting, so the hard work you put into setting up hard-to-setup Webtunnel bridge was NOT in vain!

Hi, could you share any evidences of blocking webtunnel so we can verify it?

Of all the bridges, only Webtunnel works for me on Windows 10 and Android. But I have to sort through and look for those that actually work. After a few weeks, they also stop working, so I have already changed them several times.

logs

curl

$ curl -v4 https://bw.jackyes.ovh --connect-timeout 30

  • Trying 37.187.108.188:443…
  • Connected to bw.jackyes.ovh (37.187.108.188) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • Operation timed out after 30001 milliseconds with 0 out of 0 bytes received
  • Closing connection 0
    curl: (28) Operation timed out after 30001 milliseconds with 0 out of 0 bytes received

torsocks

1750684376 DEBUG torsocks[38021]: Socks5 sending connect request to fd 5 (in socks5_send_connect_request() at socks5.c:459)
1750684496 DEBUG torsocks[38021]: Socks5 received connect reply - ver: 5, rep: 0x06, atype: 0x01 (in socks5_recv_connect_reply() at socks5.c:518)
1750684496 ERROR torsocks[38021]: Connection timed out (in socks5_recv_connect_reply() at socks5.c:547)
1750684496 DEBUG torsocks[38021]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
curl: (7) Couldn’t connect to server
1750684496 DEBUG torsocks[38021]: [close] Close caught for fd 3 (in tsocks_close() at close.c:33)
1750684496 DEBUG torsocks[38021]: [close] Close caught for fd 4 (in tsocks_close() at close.c:33)
1750684496 DEBUG torsocks[38021]: [onion] Destroying onion pool containing 0 entry (in onion_pool_destroy() at onion.c:148)

These are easier to check without torsocks as working ones supposed to give normal server reply. Just dig and curl is enough.

I also noticed a lot of genuinely dead bridges distributed over bridgedb which can give bunch of false-positives from people falsely thinking it’s related to censor. Some of those don’t even have associated domains with them anymore, this is why it’s good idea to check if server even has working domain before adding them to torrc, then curl can check for TLS availability.

There was also a thread on ntc about it, they claim only few are IP blocked, some speculate that a lot of those IP blocked bridges are either related to an ongoing war on CDNs as collateral damage or reusing entry nodes IP range.

But this is why I usher relay operators to avoid major hosting providers, right now it’s more stable when bridge hosted on random Pi in your grandma’s house.

2 Likes

Thank you! I can confirm that some webtunnel bridges are blocked.

I’ve created this issue:

1 Like