Obfs4 bridged using dual stack. ipv4 and ipv6

Support Relay Operator
1

I like to run a obfs4-bridge, responding to ipv4 and ipv6. I have a setup that gives an error. I am sorry but I do not recall the exact error message. I do not dare to restart the bridge to often to reproduce the error. It is running with an average of 20Mbit/s, it might disturb TOR users. May be some can point out how to configure obfs4 for dual stack. This is my current torrc file. What should be changed or added.

# Ports shown here are not the true ports. I use privileged ports < 1024
# Any private information has been replaced by something I made up
# The comments after the lines will be removed before restarting the service
#
# Enable both IPv4 and IPv6 for the Tor client.
ClientUseIPv4 1
ClientUseIPv6 1

# Specify both the IPv4 and IPv6 addresses
Address 11.222.333.444  # IPv4 address of the external router
Address aaaa:bbbb:cccc:1:ddd:eeee:fffff:gggg  # IPv6 address of the pc running the bridge

# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port.

ORPort 9003  # IPv4 and IPv6 ORPort

# Server transport plugin for obfs4.
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy

# Specify the obfs4 listener ports for both IPv4 and IPv6.
ServerTransportListenAddr obfs4 0.0.0.0:9004  # IPv4
ServerTransportListenAddr obfs4 [::]:9004  # IPv6

# Local communication port between Tor and obfs4. Always set this to "auto".
ExtORPort auto

# Contact information for issues with your bridge (optional).
ContactInfo any@email.addr

# Pick a nickname for your bridge (optional).
Nickname beUncensored
2

You should add a logging mechanism, so it will be easier for everyone to know what is wrong (guessing is usually bad, when not needed):

Log notice file /your/dir/notices.log

If you want a bridge, I guess this is missing:

BridgeRelay 1

Does your bridge show up on metrics? https://community.torproject.org/relay/setup/bridge/
Are you able to use it?
Also check instructions for your case: https://community.torproject.org/relay/setup/bridge/

1 Like
3

I am not able to use the metrics. I found the information in file /var/lib/tor/pt_state/obfs4_bridgeline.txt
I had to lookup my fingerprint using sudo journalctl | grep Tor | grep fingerprint
So I could gather all information needed. But I do not know how to put that in the Tor browser.

I checked the instructions. My torrc file is based on the link you mentioned, where I used the Debian link

Can that log line be added to torrc literately as given by you:

Log notice file /home/me/tor/notices.log

I gave it all permissions possible using chmod 777 for the directory and chmod 666 for the file itself.

journalctl also reports

Auto-discovered IPv6 address [aaaa:bbbb:cccc:1:ddd:eeee:ffff:gggg]:xxx has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address

My firewall is exclusive. It allows all INPUT and OUTPUT, with the exception of ports {22, 53, 853} on INPUT. They are only accessible via the local network (intranet)

On the external router (Fritxbox 7590) that pc running the obfs4 bridge and standalone snowflake-proxy, is defined as an so called exposed hosts, NAT’ting all traffic to that pc.

command ss -tuln | grep <ORPort> says it is listing at 0.0.0.0:xxx and [::]:xxx

4

Suggestion:

ORPort 127.0.0.1:auto
ORPort [::1]:auto

ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 YOURPUBLICIPv4IP:9004  # IPv4

ExtORPort auto

ContactInfo any@email.addr
Nickname beUncensored

Log notice file /home/me/tor/notices.log

BridgeRelay 1
AssumeReachable 1
AssumeReachableIPv6 1

Ok, imho your situation is tricky, assuming you want to hide your bridge as good as possible.
Afaik the exposure of an ORPort on bridges is not advised anymore. Thus I recommend to only listen on localhost for ORPorts. As far as I understood this creates the problem, tor does not know which external IP to use for ServerTransportListenAddr, thus I recommend to use your public IPv4 of your router here (if it does not change regularly and you are fine with not using your IPv6 for the bridge). If it does change often, I recommend using a DynDns service in combination with a CNAME on another domain and set up a WebTunnel bridge instead of an obfs4…

If you do not want to hide your ORPort, you might also follow this approach and set
ServerTransportListenAddr obfs4 0.0.0.0:9004 again. [tor-relays] Q about: The IPv4 ORPort address <IP> does not match the descriptor address

NoAdvertise & NoListen → Tor Project: manual

All from my point of view and with my current state of information, which is obviously limited :wink:

You are able to test your bridge, when you create a bridge line and use it from a separate connection, e.g. a WiFi hotspot

1 Like
5

Specifying ORPort without any address results in 2 log messages from Tor servers:

Now checking whether IPv4 ORPort <my ipv4 address>
Now checking whether IPv6 ORPort <my ipv6 address>

Explanatory note: <my ipv4 address> is the address of my external router, and <my ipv6 address> is the global ipv6 address of the pc running the obfs4-bridge service.

That gives me the impression the TOR servers gets both addresses. I also tested that ipv6 is accessible by using command sudo nc -6 -vz <my ipv6 address> <port>, which responds "succeeded!". Using the global ipv6 address makes sure it is not using the intranet but the external router. Would it make sense to define the ORPort explicitly for both address families, like

ORPort 0.0.0.0:<port>
ORPort [::]: <port>

or

ORPort <my ipv4 address>:<port>
ORPort <my ipv6 address>:<port>

Someone advised to add both addresses, would that make sense?

Address <my ipv4 address>
Address <my ipv6 address>

What is the purpose of ORPort 127.0.0.1:auto It listens to the loopback interface, not reachable for the outside world.

I am not sure I interpret the man page for AssumeReachable correctly, but it might allow for faster bootstrapping. That could be very handy when restarting the tor service. I am very reluctant restarting the tor service. I am afraid it can be frustrating for all Tor users connected.

You suggest to specify my ipv4 address at the ServerTransportListenAddr instead of specifying 0.0.0.0:9004. I can give it a try and also add a ServerTransportListenAdd for my ipv6 address [::]:9004

To be honest, both GitLab links you included do not mean much to me.

Off topic. Is there a way testing the obfs4 bridge in a way it is not accessible for Tor users. I do not like upsetting them to often?

If I can not get it running listening to boet address families, I will stop experimenting. If I recall it correct, you said it is not necessary to support ipv4 en ipv6.

The debian instruction page features a minimized setup.

Atari, thanks for your support.

6

So, the big problem with having an exposed ORPort is: A censor will actively scan for them on the internet. If the censor finds it, your IP will be banned and a user in need won’t be able to use your bridge from the censored counties, which enumerated and blocked your IP.
As a bridge, your bridge has to be able to connect to the tor-network and the user has to be able to connect to your bridge. The user is not able to use the tor network without a bridge, so you or anyone else building it is necessary. Your bridge does not need to have an exposed ORPort to function…

The GitLab links will make more sense, when you stop exposing your ORPort and tor is not able to correctly detect your public IP for the bridge because of your NAT.

Off topic: You may monitor this URL for the status of your bridge:
https://bridges.torproject.org/status?id=XXX

Where XXX is the non-hashed fingerprint of your bridge, usually found in /var/lib/tor/fingerprint

oldFashionIBM, you are welcome.

1 Like
7

Thank you Atari for your kind words. It’s is indeed my intention to used regular ports < 1024 instead of well know ports used for TOR trafficking to avoid a censor will ban me.

I do not have a fingerprint file, but could find the fingerprint in the log file and successfully checked my bridge was up and running using the link you provided. The next challenge will be a VPS running an exit relay.

Thanks for your support.

1 Like
8

After a little more thinking I would like to suggest the following setup:

Should work that way, but do not have a setup at home to test.
This way the obfs4proxy does not know its public IP, but will take the ORPort as public IP. It is not open for the public but in the non published descriptor. Please try if you like and report back, if it works for you or not…

3 Likes
9

Thank you Atari. I stored you proposal as a guideline on the pc. I will configure the ORPort with my public IPv4 en IPv6 address. What is the advantage set set the ORPort to “auto”? I think I will also try to set the ServerTransportListenAddr objs4 [PublicIPv6]:9004. I guess it will not hurt. But I first have to do some basic checks to see if I can reach the ORPort from the outside. tcpdump indicates that IPv6 traffic is flowing in both directions. I need to dig deeper to see if the error is not somewhere completely different.

10

Guess you are only able to have one directive of ServerTransportListenAddr, otherwise there will be another instance of obfs4 with different fingerprints and keys…

You don’t have to set auto, you may also choose on your own, but because it is not open for incoming connections, it does not matter and can be chosen by a fair dice :wink:

1 Like
11

I will come back to this. I dropped a support ticket at the helpdesk of the external router. As far as I could check the “exposed host” setting (DMZ) is working for IPv4 but not for IPv6. An initial IPv4 connection form the outside shows up in the Network monitor (tcpdump), but not for a initial IPv6 connection. We get this solved. Thanks so far for your extensive support, I really appreciate it a lot, more then I can say.

1 Like