Hi, I ran into some new IP space and I decided to change a cluster of obfs4 bridges that are more than 4 year old. When I set them up I don't remember spending so much time. So, Debian latest and Tor latest from deb.torproject.org nightly. GoLang from the official website (as it's the latest version) and obfs4proxy cloned from its default git repository. 1. The page at https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs a small revision. This page must be changed, for Debian it doesn't work simply $ edit tor@.service tor@default.service , change to NoNewPrivileges=no, save and quit. For me it only worked by editing /lib/systemd/system/tor@.service and /lib/systemd/system/tor@default.service with NoNewPrivileges=no and then: $ sudo systemctl daemon-reload. Setcap command is ok but it also need to mention to install the package in Debian libcap2-bin as well as an additional step: Under Debian, if obfs4proxy is installed in a different place, for example like in its git documentation /usr/local/bin/obfs4proxy then you also need to edit this file: /etc/apparmor.d/abstractions/tor and add one line (or change the default obfs4proxy line to): /usr/local/bin/obfs4proxy Pix, Substitute path if different and then: $ sudo systemctl restart apparmor. ------------------------------------------------ 2. It was recommended on the mail list that obfs4 bridges should not open their ORPorts publicly to prevent scanning the entire 1-65536 port range and determine it's a Tor bridge. OK. But if you try: ORPort 127.0.0.1:auto ORPort [::1]:auto AssumeReachable 1 # needed to skip ORPort reachability test Tor will start but it will constantly complain in the log with: [warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. [warn] The IPv6 ORPort address ::1 does not match the descriptor address REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. I guess it's OK to continue to run it even with this as I do understand the log messages and it's the desired effect, but isn't it confusing for less experienced users? They might think something is wrong when it is not. The recommended way is to add a simple logic to skip that check, because we can't remove it, it's vital necessary for relays (not bridges) behind NAT or dynDNS or whatever. So if BridgeRelay 1 is set and $some_transport enabled, ignore the ORPort and descriptor check / log. and instead check the pluggable transport if port open and listening. Or even better, code a pluggable transport port reachability test before building and uploading the descriptor, by cloning the code that does this for ORPorts to the pluggable transport ports. This would need a proposal that covers all use cases. 3. ServerTransportListenAddr can be used just once and it's difficult for dual-stack which is now the vast majority. It's known for many years that each pluggable transport supports just one ServerTransportListenAddr line, the second one is simply ignored. Tickets for this exist. So what is the best way to for an user to open both IPv4 and IPv6 pluggable transport ports? In Debian I have achieved it by using as wildcard ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian binds to all IPv4 and IPv6 addresses on all interfaces, but this might not be the same for all operating systems. Also, how does BridgeDB determine in case wildcard [::] is used if the pluggable transport is IPv4, IPv6 or both? Which one is used when BridgeDB sends this bridge to clients?