So I had been running my #OBFS4 Relay behind my Bell Fiber modem w/o issue & decided to move it behind my #UniFi UXG Lite gateway.

I set the server (running Debian) to DHCP & created the port forwarding rules on the UXG. It looked OK but I started to get the "Your server has not managed to confirm reachability for its ORPort(s) at xxx.xxx.xxx.xxx:ZZZZ.

I troubleshot the issue with my buddy Julien & we found the issue was with Home Hub 4000 (HH4K) and the Advanced DMZ. Even though the UXG was showing a public IP on the WAN Port and the HH4K was showing that the port the UXG is plugged into is configured for Advanced DMZ, traffic was not being passed back & forth.

I disabled the HH4K DMZ & reserved a DHCP IP for the UXG & created a port forwarding rule for the TOR ports on the HH4K to the UXG. Then on the UXG, I created port forwarding rules from the WAN IP, which is now an internal IP, to the Relay server.

After a reboot, things came back online.

In the last 24h we created 81 GB traffic.
Flaky: 10 GB, Obsy: 71 GB

Have a nice evening with free access to the internet.
Obsy and Flaky

#WhatsMissing: A tool to check if #TorBridges are still available/online/reachable that one can use either #standalone (with #TorBrowser and/or #Tor Expert Bundle) or on @tails_live / @tails / #Tails.

• Cuz I do run into issues and kinda want to sort #Bridges by availability so I don't waste time on a #TorBridge that is down and also thin-out the list of bridges that ain't online anymore.

Whilst I do acknowledge that @torproject do disrecommend having a huge list of Tor Bridges on hand, I do regularly need them for contacts who are behind a #GreatFirewall and can't #SSH-Tunnel out of it.

• Sadly #BridgeDB doesn't offer good #filtering options so one can't just query types effectively like "I need #webtunnel on #IPv4" or "I can only use Ports 80 & 443 on #IPv6" which may work.

Espechally being able to filter for #IPv4only and not just #IPv6only is something I miss, alongside the filter for #PluggableTransports type as @guardianproject #Orbot seems to only handle #obfs4 and not webtunnel or #meek at all...

• I'm pretty certain that merely pinging a bridge at it's port isn't working as a shure-fire way to check for it's availability.

Recently we upgraded our #Tor #obfs4 bridge relay from Ubuntu 22.04 to 24.04. Unfortunately we missed a permissions issue with obfs4 that changed with the upgrade. This kept Tor in a restart loop and prevented anyone from using the bridges. This has been corrected.

This were the errors:

[warn] Server managed proxy encountered a method error. (obfs4 listen tcp 23.129.64.90:443: bind: permission denied)

[warn] Managed proxy '/usr/bin/obfs4proxy' was spawned successfully, but it didn't launch any pluggable transport listeners!

We also have a #WebTunnel bridge that was not affected since it's on the disobey.net server.

https://emeraldonion.org/bridges/

One thing that @torproject is missing is a way to check availability and reachability of #Bridges with a simple tool.

• This is kinda vital as I do occasionally setup private #bridges and also want to enshure the private #TorBridges list I have is up to date.

Manually adding/removing one #bridge after the other in #TorBrowser and see if those connect is a relatively inefficient process and merely pinging them isn't viable either, espechally on #meek, #obfs4 and #snowflake type bridges.

• Now to make the obvious clear: I'd NEVER publicly list any #TorBridge on my lists.d repo obviously, because that would only harm #Tor...

I'm not even asking for like a fancy tool that is as clean as @micahflee 's #OnionShare but merely a #CLI thing (if necessary I'd build some #bash script) to automatically attempt to connect to said bridge and either spit out an ok or error.

• Something one can just feed with a text file and that'll spit out a different file with ok/working bridges and/or discards the non-working ones from the list.

And yes, this tool is kinda crucial as I want to quickly sift through a load of bridges that work on restricted ports (22, 80, 443) and thus can bypass the #GreatFirewall and #Roskomnadzor filtering...

• So people fleeing can at least safely communicate.

If anyone at #TorProject needs more details, I'll gladly exchange them in a secure manner.

• I also applied for a #gitlab account so I can help improve #documentation (ideally with some nice step-by-step screenshots so even "#TechIlliterates" can i.e. add a #bridge)...

So I am running a #Tor "farm" at home. It had consisted of 2 older #Wyse Terminals running #Ubuntu Server Minimized. One server was a #obfs4 bridge and the other was a #Snowflake proxy server.

I decided to port these machines to VMs running Ubuntu 24.04 & ran into some issues. On a whim, I decided to spin up a #Debian VM for the #obfs4 bridge last night, fully expecting to wake up to an issue this morning. I was wrong. The bridge is online & appears to be working. It was always a fight with Ubuntu, not the case with Debian.

So I spun up another Debian VM for the Snowflake proxy & it now also online and working 100%.

All hail Debian???

My physical #tor #obfs4 Bridge and #snowflake Proxy Servers have been retired and replaced by two VMs running on a #ubuntu Server.

We're excited to have published a new @torproject WebTunnel bridge hosted by disobey.net!

Details are on https://emeraldonion.org/bridges