Hello,
I'll consolidate a few e-mails since replies are spread out.
On Mon, 27 Oct 2014 18:24:49 -0400 Steve Snyder swsnyder@snydernet.net wrote:
Does obfs4 support IPv6 addresses? If so, does it work like ORPort in that it is just a matter of adding another line?
For example, to add an IPv6 address can I just replace
ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__with
ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__ ServerTransportListenAddr obfs4in the config file?
Ooof. "kind of". Pluggable Transport IPv6 support needs a lot of love and is one of the things on my TODO list. The obfs4proxy server code should support IPv6 as well as any other PT, but a lot of the tor and BridgeDB side needs a lot of love before I would consider things well supported.
In particular, the following bugs need to be solved before dual stack bridges are really what I would consider fully functional (regardless of transport, all PTs are affected by these issues).
* https://trac.torproject.org/projects/tor/ticket/7961 * https://trac.torproject.org/projects/tor/ticket/11211 * https://trac.torproject.org/projects/tor/ticket/12138
If you are running a private bridge, or wish to hand out IPv6 addresses to people on your own, then things will "work", till then IPv4 PT bridges are far more useful.
In the obfs4 case, there also is the problem that goptlib exposing a SOCKS4 interface vs SOCKS5 (required for IPv6 client use), so even if the server listens on IPv6 (and it should if told to do so, and also will automatically in certain cases), the client code can't use IPv6 bridges.
* https://trac.torproject.org/projects/tor/ticket/12535
The code is done, but needs more testing, probably in the Tor Browser alpha series.
For now, I would recommend running most PT bridges on IPv4, with the exception of bridges that are manually distributed. Fixing all of this is on my ever growing TODO list, but unfortunately keeps getting pushed back by bigger things being on fire.
Can I use the same ExtORPort for both IPv4 and IPv6 addresses?
The ExtORPort doesn't need to be public because it's only used for communicating between the pluggable transport server code and the tor daemon. So, yes the same one is fine, and I would recommend auto since it only needs to run/work on the loopback interface, unless your configuration is extremely exotic.
One more question: how can I test the functionality of obfs4proxy given that TorBrowser v4.0.0 doesn't support this transport?
You could either "Wait for Tor Browser 4.5-alpha" which I am told will happen "Soon", or run a tor instance and edit the torrc to use your bridge. The same obfs4proxy binary also acts as the client.
The relevant torrc bits for a client would be:
UseBridges 1
# The bridge line from /var/lib/tor/pt_state/obfs4_bridgeline.txt on # the bridge, edited to replace the placeholders. Bridge obfs4 .....
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
Regards,