Bug: improperly bound listen addresses?

[grarpamp]

Hi. I have various alias addressing on my interfaces. I mapped
everything to rfc1918 space for this note.

fxp0:
 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
 inet 10.0.0.2 netmask 0xffffffff broadcast 10.0.0.2

I fire up a statically compiled tor in a chroot populated with the
minimum required to keep tor quiet:

/etc/resolv.conf
/dev/urandom

I exec tor while already under a dedicated non-root user/group.
I use the following addressing options:

 -socksport   9050 -sockslistenaddress   127.0.0.1
 -controlport 9051 -controllistenaddress 127.0.0.1
 -orport  9001 -orlistenaddress  10.0.0.2
 -dirport 9030 -dirlistenaddress 10.0.0.2

Note that my packet filters have proper holes for Tor.

========================================

As you can see, the OR and DIR binds honor the requested use of the
secondary address. Yet the udp and outbound connections bind to the
primary address on the interface.

# before outboundbindaddress
tor      tor      55099    4 tcp4   10.0.0.2:9001   *:*
tor      tor      55099    5 tcp4   10.0.0.2:9030   *:*
tor      tor      55099    6 tcp4   127.0.0.1:9050  *:*
tor      tor      55099    7 tcp4   127.0.0.1:9051  *:*
tor      tor      55099    8 tcp4   10.0.0.1:1854   86.59.21.38:443
tor      tor      55099   12 tcp4   10.0.0.1:1856   128.31.0.34:9001
tor      tor      55099    9 udp4   10.0.0.1:3093   w.x.y.z:53
tor      tor      55099   11 stream tor[55103]:12
tor      tor      55103    9 udp4   10.0.0.1:3093   w.x.y.z:53
tor      tor      55103   12 stream tor[55099]:11

So I added this to the config:

 -outboundbindaddress 10.0.0.2

Now you can see that this was indeed honored as well. And we are
now left with only the udp binds to deal with. However, I can see
no configuration option to do that.

So that is missing feature #1.

# after outboundbindaddress
tor      tor      82854    4 tcp4   10.0.0.2:9001   *:*
tor      tor      82854    5 tcp4   10.0.0.2:9030   *:*
tor      tor      82854    6 tcp4   127.0.0.1:9050  *:*
tor      tor      82854    7 tcp4   127.0.0.1:9051  *:*
tor      tor      82854    8 tcp4   10.0.0.2:2601   86.59.21.38:443
tor      tor      82854   12 tcp4   10.0.0.2:3605   91.143.80.22:9001
tor      tor      82854    9 udp4   10.0.0.1:2228   w.x.y.z:53
tor      tor      82854   11 stream tor[82856]:12
tor      tor      82856    9 udp4   10.0.0.1:2228   w.x.y.z:53
tor      tor      82856   12 stream tor[82854]:11

========================================

Now note that _both_before_and_after_ outboundbindaddress, Tor seems
to be confused regarding its socket allocation as noted below.
Therefore it never publishes its descriptor and I have 384kbits
still sitting useless :-) :-(

So that is bug #2.

[n] Tor v0.2.0.30 (r15956) ... (FreeBSD i386)
[n] Configuration file "/.../etc/tor/torrc" not present, using
reasonable defaults.

[n] Opening OR listener on 10.0.0.2:9001
[n] Opening Directory listener on 10.0.0.2:9030
[n] Opening Socks listener on 127.0.0.1:9050
[n] Opening Control listener on 127.0.0.1:9051

[n] Now checking whether ORPort 10.0.0.1:9001 and DirPort
10.0.0.1:9030 are reachable... (this may take up to 20 minutes
-- look for log messages indicating success)

[w] Your server (10.0.0.1:9001) has not managed to confirm
that its ORPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.
[w] Your server (10.0.0.1:9030) has not managed to confirm
that its DirPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.

========================================

Lastly, I think the pairing of:
-<Whatever_function>Port Port
-<Whatever_function>ListenAddress IP[:PORT]

is a bit klunky. In that the pure Port statement is required to
enable the function. But if you also want to bind it somewhere
deterministic you _also_ have to specify the Address IP. And some
functions may be useful to bind more than once in the future. So I
would perhaps see about moving to this style instead:

-<Whatever_function>ListenAddress "{IP|*|#}[:PORT]"

Where '*' means bind to all addresses. And perhaps '#' might refer
to however the current pure Port statement picks its addresses
currently.

========================================