Improperly bound listen addresses
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:
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.
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 220.127.116.11:443 tor tor 55099 12 tcp4 10.0.0.1:1856 18.104.22.168:9001 tor tor 55099 9 udp4 10.0.0.1:3093 w.x.y.z:53 tor tor 55099 11 stream tor:12 tor tor 55103 9 udp4 10.0.0.1:3093 w.x.y.z:53 tor tor 55103 12 stream tor:11
So I added this to the config:
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.
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 22.214.171.124:443 tor tor 82854 12 tcp4 10.0.0.2:3605 126.96.36.199:9001 tor tor 82854 9 udp4 10.0.0.1:2228 w.x.y.z:53 tor tor 82854 11 stream tor:12 tor tor 82856 9 udp4 10.0.0.1:2228 w.x.y.z:53 tor tor 82856 12 stream tor: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 legacy/trac#2 (closed).
[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:
Where '*' means bind to all addresses. And perhaps '#' might refer to however the current pure Port statement picks its addresses currently.
If you're a relay, tor will attempt to do name resolution for clients, perhaps this is what you're seeing.
Yes. And it should have the facility to bind to whatever address I tell it to use for that purpose. Not the primary address on any given interface, the '*' address, etc. Tor already has facilities for its OR and DIR 'listeners' and the 'outboundbindaddress'. It needs one one for DNS resolution as well. I don't want it using .1 for that. Create a -dnssrcport and -dnsbindaddress. -dnssrcport should allow >=1024 for non-root and anything for root, particularly 53.
Note that Tor still performs some tor related DNS queries even if it is: 'reject :'. Otherwise there would be no need to bind udp in that case.
[w] Your server (10.0.0.1:9001) has not managed to confirm
Because tor can't confirm 10.0.0.1 is a valid non-rfc1918 address.
No. As with w.x.y.z:53, I have protected the innocent for this note. In your mind, do the reverse and replace every instance of 10.0.0.0/24 above with one publicy routed /24 cidr block while preserving the last octet. Then it is clear that something is wrong. I have bound OR, DIR and the 'outboundbindaddress' to .2. It thinks otherwise.
[Automatically added by flyspray2trac: Operating System: All]