Currently seeing this error spamming logs on our WebTunnel bridges (Docker):
Dec 01 06:03:30.000 [notice] Unable to find IPv6 address for ORPort 48343. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 seconds]
I’ve confirmed our IPv6 port/address is reachable. I think this is a Docker issue but am unsure what/where. Does anybody know how I can fix this error and enable IPv6 on our bridges?
Cheers,
Alec
<no warranty for nothing - works for me^^>
First of all, this will not stop the spamming your logs, there will be new/other warnings but IPv6 should work (at least it did for me)… 
Assumption: You used these instructions Tor Project | WebTunnel Docker setup
Your .env should have these additional lines (and you may remove the GENEDORPORT-line (number 4 from instructions):
WEBTUNNEL_ENABLE_ADDITIONAL_VARIABLES=1
WEBTUNNELV_AssumeReachable=1
WEBTUNNELV_ORPort=[::1]:auto IPv6Only
docker-compose.yml should be adapted like this (I removed watchtower):
networks:
wtb_net:
enable_ipv6: true
driver: bridge
ipam:
driver: default
config:
- subnet: 2001:db8:1::/64
gateway: 2001:db8:1::108
services:
webtunnel-bridge:
restart: always
environment:
- NICKNAME=$BRIDGE_NICKNAME
- PT_PORT=15000
- OR_PORT=127.0.0.1:auto
- EMAIL=$OPERATOR_EMAIL
- WEBTUNNEL_URL=$URL
- WEBTUNNEL_ENABLE_ADDITIONAL_VARIABLES=1
- WEBTUNNELV_AssumeReachable=$WEBTUNNELV_AssumeReachable
- WEBTUNNELV_ORPort=$WEBTUNNELV_ORPort
volumes:
- 'webtunnel-tor-state:/var/lib/tor'
user: debian-tor
ports:
- '127.0.0.1:15000:15000'
container_name: webtunnelBridge
image: 'thetorproject/webtunnel-bridge:latest'
networks:
wtb_net:
ipv6_address: 2001:db8:1::256
volumes:
webtunnel-tor-state:
Explanation:
ORPort in environment is set to 127.0.0.1:auto → It should not be reachable from outside (see).
Also via WEBTUNNELV_ORPort=[::1]:auto tor is instructed to use IPv6.
So consequently the line - '$GENEDORPORT:$GENEDORPORT' is removed, because ORPort will not be exposed.
Additionally a new network with IPv6 is defined and started, when the container is running. This might need to be adapted to a different subnet, if you have other IPv6 containers on your host.
@atari, you are the guardian angel of relay operators. Thank you so much for the write-up. I’ll make the recommended changes and update this thread later.
Hi again @atari!
Your guide worked great for me, everything seems to be up and running on my end.
The only weird thing I’m noticing is when trying to test my bridges. Some of them work fine, but others have trouble. I’m not sure if it’s an unrelated bug in Tor Browser or what:
2024-12-03 19:03:53.274 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2024-12-03 19:03:53.280 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2024-12-03 19:03:53.280 [NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
2024-12-03 19:03:53.280 [WARN] Cannot find maximum file descriptor, assuming: 256
2024-12-03 19:03:54.278 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
2024-12-03 19:03:54.280 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
2024-12-03 19:03:54.557 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
2024-12-03 19:03:54.634 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
2024-12-03 19:03:54.718 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
2024-12-03 19:03:54.718 [NOTICE] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
2024-12-03 19:03:54.788 [NOTICE] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
2024-12-03 19:03:57.379 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
and then it just hangs for seemingly infinite amount of time, duplicating the last [NOTICE] periodically.
@atari Something concerning that I found is if the ORPort is set, then Tor Metrics leaks the IP:
Both are private IPs (IPv4)/IPv6).
And additionally seems to be the wanted behavior: See here: IPv4/IPv6
Ah, I see now. Somehow I didn’t notice they were private IP’s. Thanks so much!
Did you restart the TBB after configuring and testing the WebTunnel bridge? Sometimes have the same problem, TBB does not always properly connect, when I change bridges. A restart mostly fixes it…
Otherwise it would be odd. For the bridge side: Same server OS? Same provider? Same IP-config (IPv4/IPv6)?
You could compare logs if the TBB restart does not help and compare the entries for differences. docker exec webtunnelBridge cat /var/log/tor/log
And compare .env and docker-compose.yml - otherwise containers should all more or less act the same.
