tor uses default IP for dirport instead of the one defined in DirPort

When setting up torland relays for ipv6 with Linus @ 30C3 we stumbled over the following error.

I have the following setup:

default ip a.b.c.d

torrc

ORPort a.b.c.33:443 ORPort [xxx6]:443 DirPort a.b.c.33:80
OutboundBindAddress a.b.c.33 OutboundBindAddress [xxx6]

If I start up tor, I get the following error message:

---

Your server (a.b.c.d:80) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

I need to have the parameter

Address a.b.c.33

in my torrc in order not to get the error.

regards,

torland

Trac:
Username: torland

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified needs-design parent::19919 priority::low reporter::torland severity::normal status::new tor-relay torrc type::defect usability version::tor 0.2.4.18-rc labels

Trac:
Username: torland
Summary: tor uses default IP for dirport progagating instead of if the one defined in DirPort to tor uses default IP for dirport instead of the one defined in DirPort

I think this is either a UI problem or a documentation problem, and we can decide which. Right now, "Address" is the address you advertise; the orport address doesn't affect that.

Option 1:

• Fix all our documentation to explain why Address is necessary.

Option 2:

• Figure out how these options should interact, figure out the best way to move from there to here, and go for it.

Option 3:

• Do 1, then do 2.

1 is easiest; anybody want to write a patch?

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: unspecified

I still don't understand why not having the "Address" Parameter set leads to

Your server (a.b.c.d:80) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Actually I have set it with DirPort a.b.c.33:80

so I would assume that it is reachable. What is "Address" good for? What do clients get when they connect to "Address"? My understanding was that what is in ORPort and DirPort gets listed by the directory servers. So why is Address needed?

Trac:
Username: torland

So, as Tor stands now, the Address field (or the guessed address) is what's taken as your node's address when it advertises itself. The ORPort and DirPort variables decide which address:port to bind, and which port to advertise, but not which address to advertise.

Here's how I remember it. Originally, Address could only be an address (as in 1.2.3.4), and ORPort could only be a port (as in 9001), so there was no reason to infer the address from the ORPort. Later, ORPort and DirPort got the possibility to explicitly include an address, to say which address to listen to, in order to merge ORListenAddress ... but the ability to advertise an address never got added to ORPort (except for secondary IPv6 addresses for bridges, maybe?)

Needless to say, this is more complicated than it should be. We should try to come up with a better way for it to work.

This bug is actually a bit worse than the original description would make it appear. This problem actually applies to ORPort as well as DirPort (in 0.2.4.22 at least) and depending upon what is running on the default IP can make you think your relay is working correctly even when it is not. A config containing:

ORPort a.b.c.33:443 OutboundBindAddress a.b.c.33

but no Address will get:

[notice] Now checking whether ORPort a.b.c.d:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)

where a.b.c.d is the default IP. Depending upon what else is running on the box ???? you will then get one of:

[warn] Your server (a.b.c.d:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

but either way the relay will not actually show up in the directory. Again, even though it says "Publishing server descriptor", if Address is not set and ORPort is not the default IP then the relay will not actually get published.

Trac:
Username: Pascal

Trac:
Username: Pascal
Cc: linus@torproject.org to linus@torproject.org, Pascal@rkfd.com

Replying to Pascal:

[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

but either way the relay will not actually show up in the directory. Again, even though it says "Publishing server descriptor", if Address is not set and ORPort is not the default IP then the relay will not actually get published.

This sounds like it might be a different bug -- if you get that log line, Tor should be generating a descriptor and uploading it. Can you describe more clearly how to reproduce this issue?

Replying to arma:

This sounds like it might be a different bug -- if you get that log line, Tor should be generating a descriptor and uploading it. Can you describe more clearly how to reproduce this issue? My guess would be Tor IS generating a descriptor and uploading it, but the authorities are rejecting it because Tor is not actually running on the advertised ORPort.

To reproduce you will need a server with at least two IPs. Set ORPort and OutboundBindAddress to the second IP and do not have an Address line in the config. Tor will detect the first IP and try to advertise it even though it is running on the second.

Trac:
Username: Pascal

Replying to Pascal:

My guess would be Tor IS generating a descriptor and uploading it, but the authorities are rejecting it because Tor is not actually running on the advertised ORPort.

Agreed. More specifically, what I would guess is happening here is that there was a working, published Tor relay on the other IP address not long earlier, and some clients knew about it. So when the new Tor relay came up, it started doing self-testing of the address that it was going to publish (and all of that self-testing failed), but at the same time some working connection came in on the old address, and the self-testing mechanism considers that close enough, and published the doomed descriptor.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Reviewer: N/A to N/A

Replying to nickm:

Option 2:

• Figure out how these options should interact, figure out the best way to move from there to here, and go for it.

I wonder if Tor should notice that the ORPort and/or DirPort have an IP address listed in them, yet Address is not set, and warn in this case? If we wanted to get slightly smarter, we could only warn when Address is not set and the address we decide is different from the one in ORPort or DirPort.

(Who knows, maybe we already thought of this and added this warning, sometime in the past 3 years? :)

Trac:
Priority: Medium to Low
Keywords: N/A deleted, tor-relay usability torrc needs-design added

We should try to fix this issue when we rewrite this subsystem in #24403 (moved).

Trac:
Parent: N/A to #24403 (moved)

If we use the DirPort address to guess the IPv4 address, then #19919 (moved) closes this issue.

Trac:
Parent: #24403 (moved) to #19919 (moved)

moved to tpo/core/tor#10519 (closed)