Discussion:
[tor-dev] Is OutboundBindAddress respected during ORPort IP auto detection?
nusenu
2018-03-24 16:17:00 UTC
Permalink
Hi,

I got an interesting bugreport for ansible-relayor [1],
that leads me to the following question:

Is OutboundBindAddress used during ORPort IP auto detection?

Imagine the following setup:

Relay with two public IPs:
1.1.1.1
2.2.2.2

Two tor instances (one per IP):

1.1.1.1:9000
2.2.2.2:9000


torrc for 2.2.2.2:9000 contains:
[...]
OutboundBindAddress 2.2.2.2
ORPort 2.2.2.2:9000
SyslogIdentityTag 2.2.2.2_9000
[...]


when starting 2.2.2.2_9000 instance the log contains:

Tor-2.2.2.2_9000[586]: Your server (1.1.1.1:9000) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Note: Reachability tests appear to try to contact the first IP for the second instance.

No NAT is involved.

The solution was to add "Address 2.2.2.2", but that was not necessary previously(?)


My assumption here:
During auto detection the OutboundBindAddress configuration directive is not relevant.

Is that the case? Or why does tor auto-detect IP 1.1.1.1 for instance on 2.2.2.2 even though OutboundBindAddress is used?

thanks,
nusenu


this is on tor: 0.3.2.10

[1] https://github.com/nusenu/ansible-relayor/issues/153
--
https://mastodon.social/@nusenu
twitter: @nusenu_
grarpamp
2018-03-24 21:15:22 UTC
Permalink
It seems that each function in a network app that
- listens to the net, should have an independantly
configurable inbound ip and port.
- talks out to the net, should have an independantly
configurable source ip and port.

And when there are multiple interfaces / NAT,
address metadata and metainfo are sometimes
needed for both others and self.

A reachability test would have both listen and talk
config parameters, and even meta needs.

Like most tools of its vintage, tor started with few knobs,
configurability often came slowly as use case bugs.

'Address' might have multi role of...
- default network interface chooser
- embed this metadata in communications / consensus for others
- for self, tell daemon who it is, where to reach self, etc

'Address' is not documented as supporting IPv6.

Seems in the above may be what you're seeing.
Maybe some more config abstraction or docs would help.

'self-test' and 'reachab' appear a few times
in limited context in the manpage.


BTW: Hyphenating these two will conform the entire
codebase to the 'self-test' form for those searching it...

tor-0.3.2.10/src/or/router.c:1461: /* XXX IPv6 self testing */
tor-0.3.2.10/src/or/router.c:1470: /* XXX IPv6 self testing */
nusenu
2018-03-25 00:54:00 UTC
Permalink
Turns out this is a known bug in tor.

s7r reported [1] it several years ago (2014-12-13).

In [1] a log warning has been added, [2] is
about the actual fix.



[1] https://trac.torproject.org/projects/tor/ticket/13953
[2] https://trac.torproject.org/projects/tor/ticket/19919
--
https://mastodon.social/@nusenu
twitter: @nusenu_
Loading...