Earlier this month I set up an obfs3/obfs4 bridge that (as far as I can tell) has never been used. Is this normal? My bridge is at https://atlas.torproject.org/#details/C184F644B9D39B26647779282003ACAF59E802...
During this exercise I ran across a few pain points for setting up a bridge. Maybe I completely ignored some existing resource for this, but the bottom of https://www.torproject.org/docs/bridges is out of date, BridgeDB doesn't have a link anywhere, and trac's search isn't that good but I couldn't find anything on that either.
1) Setup I followed https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md to set up the obfs3/obfs4 As good as this is, it would be great if it included a minimal and complete torrc for an obfs4 bridge, and perhaps also for an obfs3/obfs4 bridge and an IPv6 setup. My torrc is
SocksPort 0 ControlPort 9051 HashedControlPassword ... CookieAuthentication 1 ORPort 9001 ORPort [<public ipv6 addr>]:9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:80 ServerTransportListenAddr obfs4 [::]:443
2) Testing How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
netstat seems to say that things are good. The tcp6 connections on 80 and 443 also apply to ipv4 though; right?
$ netstat -lpn tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN 479/tor tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 479/tor tcp 0 0 127.0.0.1:55346 0.0.0.0:* LISTEN 479/tor tcp6 0 0 :::443 :::* LISTEN 480/obfs4proxy tcp6 0 0 <public ipv6 addr> :::* LISTEN 479/tor tcp6 0 0 :::80 :::* LISTEN 480/obfs4proxy
I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3.
Some external validation would be nice.
3) Usage Can do I figure out if my bridge is being used? I've identified the following:
$ cat /var/lib/tor/stats/bridge-stats bridge-stats-end 2015-05-31 18:58:43 (86400 s) bridge-ips bridge-ip-versions v4=0,v6=0 bridge-ip-transports
$ zgrep unique /var/log/tor/* (a bunch of lines of "0 unique clients")
Atlas graphs, showing virtually no traffic
I feel like #2 might be addressed by Weather (if it was working), but all of these might be a good subject for a wiki page on how to run a bridge, if my understanding of everything is correct.
-tom
- Testing
How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
FYI, you can get up to 5 IPv6 addresses for free from Hurricane Electric:
That lets you tunnel IPv6 traffic when your ISP only offers IPv4 networking, allowing you to connect to your IPv6 bridge address.
On Monday, June 1, 2015 12:34pm, "Tom Ritter" tom@ritter.vg said:
Earlier this month I set up an obfs3/obfs4 bridge that (as far as I can tell) has never been used. Is this normal? My bridge is at https://atlas.torproject.org/#details/C184F644B9D39B26647779282003ACAF59E802...
During this exercise I ran across a few pain points for setting up a bridge. Maybe I completely ignored some existing resource for this, but the bottom of https://www.torproject.org/docs/bridges is out of date, BridgeDB doesn't have a link anywhere, and trac's search isn't that good but I couldn't find anything on that either.
- Setup
I followed https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md to set up the obfs3/obfs4 As good as this is, it would be great if it included a minimal and complete torrc for an obfs4 bridge, and perhaps also for an obfs3/obfs4 bridge and an IPv6 setup. My torrc is
SocksPort 0 ControlPort 9051 HashedControlPassword ... CookieAuthentication 1 ORPort 9001 ORPort [<public ipv6 addr>]:9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:80 ServerTransportListenAddr obfs4 [::]:443
- Testing
How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
netstat seems to say that things are good. The tcp6 connections on 80 and 443 also apply to ipv4 though; right?
$ netstat -lpn tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN 479/tor tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 479/tor tcp 0 0 127.0.0.1:55346 0.0.0.0:* LISTEN 479/tor tcp6 0 0 :::443 :::* LISTEN 480/obfs4proxy tcp6 0 0 <public ipv6 addr> :::* LISTEN 479/tor tcp6 0 0 :::80 :::* LISTEN 480/obfs4proxy
I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3.
Some external validation would be nice.
- Usage
Can do I figure out if my bridge is being used? I've identified the following:
$ cat /var/lib/tor/stats/bridge-stats bridge-stats-end 2015-05-31 18:58:43 (86400 s) bridge-ips bridge-ip-versions v4=0,v6=0 bridge-ip-transports
$ zgrep unique /var/log/tor/* (a bunch of lines of "0 unique clients")
Atlas graphs, showing virtually no traffic
I feel like #2 might be addressed by Weather (if it was working), but all of these might be a good subject for a wiki page on how to run a bridge, if my understanding of everything is correct.
-tom _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Mon, 1 Jun 2015 13:23:34 -0400 (EDT) "Steve Snyder" swsnyder@snydernet.net wrote:
- Testing
How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
FYI, you can get up to 5 IPv6 addresses for free from Hurricane Electric:
https://tunnelbroker.net/
Correction: you can get up to 5 _tunnels_ (pointing to different IPv4 addresses of yours, typically each to a different host or network where you need to add IPv6);
Each tunnel provides you a /64 subnet by default, plus a /48 subnet on request (done automatically via their panel);
And each of these subnets provide you with much much more than just 5 IPv6 addresses.
On Monday, June 1, 2015 1:28pm, "Roman Mamedov" rm@romanrm.net said:
On Mon, 1 Jun 2015 13:23:34 -0400 (EDT) "Steve Snyder" swsnyder@snydernet.net wrote:
- Testing
How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
FYI, you can get up to 5 IPv6 addresses for free from Hurricane Electric:
https://tunnelbroker.net/Correction: you can get up to 5 _tunnels_ (pointing to different IPv4 addresses of yours, typically each to a different host or network where you need to add IPv6);
Each tunnel provides you a /64 subnet by default, plus a /48 subnet on request (done automatically via their panel);
And each of these subnets provide you with much much more than just 5 IPv6 addresses.
-- With respect, Roman
Yes, you are right. I've only used a single address from an allocated tunnel subnet and so mis-stated HE's offering as my own use. Thanks for the correction.
Hello everyone, I'm new here. So just wondering: why would IPv6-to-IPv4 tunnel providers like HE enjoy having extra loads of traffic for no extra profit? Or, perhaps, I'm missing somehing...
On 1 червня 2015 р. 20:14:53 GMT+02:00, Steve Snyder swsnyder@snydernet.net wrote:
On Monday, June 1, 2015 1:28pm, "Roman Mamedov" rm@romanrm.net said:
On Mon, 1 Jun 2015 13:23:34 -0400 (EDT) "Steve Snyder" swsnyder@snydernet.net wrote:
- Testing
How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
FYI, you can get up to 5 IPv6 addresses for free from Hurricane
Electric:
https://tunnelbroker.net/Correction: you can get up to 5 _tunnels_ (pointing to different IPv4 addresses of yours, typically each to a different host or network
where you
need to add IPv6);
Each tunnel provides you a /64 subnet by default, plus a /48 subnet
on request
(done automatically via their panel);
And each of these subnets provide you with much much more than just 5
IPv6
addresses.
-- With respect, Roman
Yes, you are right. I've only used a single address from an allocated tunnel subnet and so mis-stated HE's offering as my own use. Thanks for the correction.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tom Ritter transcribed 2.8K bytes:
Earlier this month I set up an obfs3/obfs4 bridge that (as far as I can tell) has never been used. Is this normal? My bridge is at https://atlas.torproject.org/#details/C184F644B9D39B26647779282003ACAF59E802...
Your bridge is in BridgeDB, and it's allocated to the HTTPS Distributor, so it should be distributed. There are just a couple slights issue (as far as I can tell):
* Your Bridge doesn't have the Stable flag. [0] BridgeDB tries really hard to make sure that, in a given response to a client: 1) At least one Bridge has the Stable flag, and 2) At least one Bridge is listening on 443.
* Neither the obfs3 nor obfs4 interfaces are listening on IPv6; they're both only on IPv4. (I think that's what you wanted, but it's a known bug [1] and just FYI.) As you likely already know, it's not currently possible to run two obfs3 simultaneously — one IPv4 and one IPv6 — and the same goes for obfs4 and every other PT. Internally, tor currently only has one slot for an "obfs3". [2] Similarly, Stem uses a Python dictionary where the keys are the pluggable transport methodnames.
During this exercise I ran across a few pain points for setting up a bridge. Maybe I completely ignored some existing resource for this, but the bottom of https://www.torproject.org/docs/bridges is out of date, BridgeDB doesn't have a link anywhere, and trac's search isn't that good but I couldn't find anything on that either.
- Setup
I followed https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md to set up the obfs3/obfs4 As good as this is, it would be great if it included a minimal and complete torrc for an obfs4 bridge, and perhaps also for an obfs3/obfs4 bridge and an IPv6 setup. My torrc is
SocksPort 0 ControlPort 9051 HashedControlPassword ... CookieAuthentication 1 ORPort 9001 ORPort [<public ipv6 addr>]:9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:80 ServerTransportListenAddr obfs4 [::]:443
- Testing
How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB?
netstat seems to say that things are good. The tcp6 connections on 80 and 443 also apply to ipv4 though; right?
Somehow, possibly due to one of the above-mentioned bugs, your tor and BridgeDB both seem to think that you're *only* listening on IPv4… so I'm a bit confused by what netstat is telling you…
$ netstat -lpn tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN 479/tor tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 479/tor tcp 0 0 127.0.0.1:55346 0.0.0.0:* LISTEN 479/tor tcp6 0 0 :::443 :::* LISTEN 480/obfs4proxy tcp6 0 0 <public ipv6 addr> :::* LISTEN 479/tor tcp6 0 0 :::80 :::* LISTEN 480/obfs4proxy
I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3.
Would it be easier, perhaps, if obfs4proxy were to also put your obfs3 (and/or scramblesuit) bridge lines into that file? (I thought it already did this, but I must be wrong.)
You had to edit it?
Some external validation would be nice.
- Usage
Can do I figure out if my bridge is being used? I've identified the following:
$ cat /var/lib/tor/stats/bridge-stats bridge-stats-end 2015-05-31 18:58:43 (86400 s) bridge-ips bridge-ip-versions v4=0,v6=0 bridge-ip-transports
$ zgrep unique /var/log/tor/* (a bunch of lines of "0 unique clients")
Atlas graphs, showing virtually no traffic
I feel like #2 might be addressed by Weather (if it was working), but all of these might be a good subject for a wiki page on how to run a bridge, if my understanding of everything is correct.
I agree that all of the FAQ-ish questions you've just mentioned should be somewhere, easily accessible, on the website. I've created ticket #16261 for updating the "Running a Bridge" portion of the bridges.html page, [3] but I'm totally open to suggestions if people think the documentation should go into the FAQ page, or on a wiki page (or link to a wiki page, so that it's easier for community members to contribute tips and ideas), or somewhere else.
[0]: https://globe.torproject.org/#/bridge/C184F644B9D39B26647779282003ACAF59E802... [1]: https://trac.torproject.org/projects/tor/ticket/12138 [2]: https://trac.torproject.org/projects/tor/ticket/11211 [3]: https://trac.torproject.org/projects/tor/ticket/16261
Thanks for running an obfs4 bridge!
On Tue, 2 Jun 2015 05:28:07 +0000 isis isis@torproject.org wrote:
[snip]
Somehow, possibly due to one of the above-mentioned bugs, your tor and BridgeDB both seem to think that you're *only* listening on IPv4… so I'm a bit confused by what netstat is telling you…
It's a Linux-ism. Binding to [::] will bind to both IPv4 and IPv6. It's initially confusing behavior, but harmless/useful (in this case more useful than anything else).
I don't think I'll change this, though I could.
I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3.
Would it be easier, perhaps, if obfs4proxy were to also put your obfs3 (and/or scramblesuit) bridge lines into that file? (I thought it already did this, but I must be wrong.)
You had to edit it?
The bridge line file only dumps the obfs4 bridge line because it's the transport with PT generated arguments (well, Dust2 will have them, but that's not merged yet).
The missing information that I have as "fill this in with the correct values" in there aren't provided to PTs at all (Eg: The fingerprint, and the inbound IP address). The fingerprint could be provided to PTs, the inbound IP address probably won't ever be because Tor doesn't know it at PT init time, and our code for guessing it needs a lot of love.
[snip]
I agree that all of the FAQ-ish questions you've just mentioned should be somewhere, easily accessible, on the website. I've created ticket #16261 for updating the "Running a Bridge" portion of the bridges.html page, [3] but I'm totally open to suggestions if people think the documentation should go into the FAQ page, or on a wiki page (or link to a wiki page, so that it's easier for community members to contribute tips and ideas), or somewhere else.
mrphs wrote up this a while back: https://tor.stackexchange.com/questions/6370/how-to-run-an-obfs4-bridge
Regards,
* Tom Ritter schrieb am 2015-06-01 um 18:34 Uhr:
Earlier this month I set up an obfs3/obfs4 bridge that (as far as I can tell) has never been used. Is this normal? My bridge is at
I'm running several bridges (plus obfs3, obfs4 and other PTs). However most of them are never used (something like 4 in 10 or less). The ones that are in use attract only a few users. The bridgte-stats constantly tell me about 8 »users« (which is the minimum value). Sometimes there are 16 or even 24 »users«. However the last case is very rare.
How do I (easily) confirm my bridge is correctly configured?
I try to build the line from /var/lib/tor/pt_state/obfs4_bridgeline.txt in the case of obfs4 and enter it into my Tor Browser. Also I set up logging for obfs4. If I open Tor Browser, open a website and see a connection attempt in the obfs4.log, I take it as a confirmation that it works.
$ cat /var/lib/tor/stats/bridge-stats bridge-stats-end 2015-05-31 18:58:43 (86400 s) bridge-ips
The above line shows between 1 and 6 different country codes which usually all equal to 8.
bridge-ip-transports
In the majority of the bridges I see <OR> (default bridge), sometimes obfs3 and almost never any other of the pluggable transports. I want to investigate why obfs4 is nearly never used.
On Sun, 7 Jun 2015 12:31:52 +0200 tor-server-creator@use.startmail.com wrote:
I want to investigate why obfs4 is nearly never used.
hi, may you want to have a look into tails bug #9268 adressing some obfs issue
You mean, a Tails issue that happens to affect obfs4 since it likes to write large-ish packets, and what may be a Linux kernel issue that possibly makes the PLPMTUD code not that great.
I have a packet capture that I need to go over but, since it is tcpdump output from a terminal and not a pcap file I've been putting it off, but the fact that TCP/IP breaks when write calls are done when the system is breaking PMTUD is not an obfs4 issue.
In sane environments where PMTUD works, obfs4 has no issues with shorter than normal MSS.
Regards,
tor-relays@lists.torproject.org
-
Dmytro Dudenko -
isis -
Jens Kubieziel -
Roman Mamedov -
Steve Snyder -
Tom Ritter -
tor-server-creator＠use.startmail.com -
Yawning Angel