Opened 5 years ago

Last modified 11 months ago

#10519 new defect

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

Reported by: torland Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.18-rc
Severity: Normal Keywords: tor-relay usability torrc needs-design
Cc: linus@…, Pascal@… Actual Points:
Parent ID: #24403 Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (12)

comment:1 Changed 5 years ago by torland

Summary: tor uses default IP for dirport progagating instead of if the one defined in DirPorttor uses default IP for dirport instead of the one defined in DirPort

comment:2 Changed 5 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: unspecified

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?

comment:3 Changed 5 years ago by torland

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?

comment:4 Changed 5 years ago by nickm

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.

comment:5 Changed 5 years ago by Pascal

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.

Last edited 5 years ago by Pascal (previous) (diff)

comment:6 Changed 5 years ago by Pascal

Cc: Pascal@… added

comment:7 in reply to:  5 Changed 5 years ago by arma

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?

comment:8 Changed 5 years ago by Pascal

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.

Last edited 5 years ago by Pascal (previous) (diff)

comment:9 in reply to:  8 Changed 2 years ago by arma

Severity: Normal

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.

comment:10 in reply to:  2 Changed 2 years ago by arma

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? :)

comment:11 Changed 2 years ago by nickm

Keywords: tor-relay usability torrc needs-design added
Priority: MediumLow

comment:12 Changed 11 months ago by teor

Parent ID: #24403

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

Note: See TracTickets for help on using tickets.