Opened 4 years ago

Last modified 2 years ago

#21044 new defect

ORPort self reachability test happens also when it shouldn't

Reported by: s7r Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor:
Severity: Normal Keywords: self-test tor-relay reachability
Cc: Actual Points:
Parent ID: #24403 Points: 3
Reviewer: Sponsor:


I think we did not cover all cases when the self reachability test before publishing descriptors was introduced.

I am running a bridge with PublishServerDescriptor 0 and ORPort because I want to run it just to do some responsible testing without hammering the public Guards used by other clients. The bridge is configured with PublishServerDescriptor 0 so it means I don't need a descriptor, I don't intend to make the bridge (or relay) public.

When a bridge is run in the conditions described above the log is spammed (exactly one log message at every 20 minutes) with:

[warn] Your server (PUBLIC_IP:443) 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.


[warn] The IPv4 ORPort address does not match the descriptor address PUBLIC_IP. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.

What it did wrong:

  • It guessed the public IP address and tried to make the self test on that address, regardless it's not the address explicitly configured at ORPort. Address is not set in this setup.
  • Based on the second log message, I think it even overwritten the address used with ORPort with the public IP address that it guessed and built the descriptor.
  • It infinitely tries once every 20 minutes and logs a message that the descriptor cannot be published (and my intention based on the options configured is exactly not to publish one even if the tests were successful).

What Tor should do:

  • Bypass the protocol to guess Address (the public IP address) when ORPort / DirPort is explicitly configured as a loopback address or NAT address. This will have a logic follow-up (which I think we already do, but want to make sure) like this:
  • Bypass self tests when ORPort / DirPort address is explicitly configured as a loopback address or NAT address (simplest thing would be to treat these cases as like AssumeReachable 1 is set). Such addresses cannot be tested from the public internet anyway.
  • PublishServerDescriptor 0 maybe should not even build a descriptor at all, or at least bypass the self tests in this case too, it does not make sense to try to test something we never want to publish. Or, only make 1 attempt to test and log a message stating success or failure.

#19919 is kind of related, it treats as it should the cases where ORPort is explicitly configured as a public address. In this ticket we cover an extension for cases where ORPort is a loopback or NAT address.

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by nickm

Milestone: Tor: 0.3.0.x-final

comment:2 Changed 4 years ago by s7r

Thinking again the protocol to guess Address is OK to be called even when ORPort is explicitly configured as a loopback or NAT address because there might be such setups. This is why there is a log message instructing about IP address mismatch and how to use NoAdvertise and NoListen flags along with Address to fix it.

So, the first two behaviors (bypass the protocol to guess Address and bypass self reachability tests) should only happen when PublishServerDescriptor 0 is set and ORPort is a loopback or NAT address, otherwise use the current behavior which is fine for cases where user wants to run a public relay / bridge.

Also, there might be use cases where one does not want to publish the descriptor but uses a separate tool that does this or just needs to export the descriptor and use it somehow, so PublishServerDescriptor 0 should build it, but not publish it as it currently does - we just need to correct the self reachability tests when this option is set.

comment:3 Changed 4 years ago by nickm

Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Deferring -- this is an area where all the changes we make tend to destabilize things.

comment:4 Changed 3 years ago by nickm

Points: 3

comment:5 Changed 3 years ago by nickm

Keywords: triaged-out-20170308 added
Milestone: Tor: 0.3.1.x-finalTor: unspecified

Deferring all 0.3.1 tickets with status == new, owner == nobody, sponsor == nobody, points > 0.5, and priority < high.

I'd still take patches for most of these -- there's just nobody currently lined up to work on them in this timeframe.

comment:6 Changed 3 years ago by nickm

Keywords: self-test tor-relay reachability added; triaged-out-20170308 removed

comment:7 Changed 2 years 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.