Our IPv6 Autodiscovery breaks AssumeReachable 1 torrc option

added IPv6 label

Could someone please assign this to me?

assigned to @neel

added Doing label

@neel please note (let me know if I should open another issue about this): besides ignoring AssumeReachable 1 torrc option, it also overrides what IPv4 ORPort we set in torrc if Address was not also set for IPv4 in the same torrc.

IPv4Only flag on the ORPort is also ignored.

For example, let's assume you have a torrc with ORPort 192.168.2.1 (no flags like NoListen / NoAdvertise) and Address is not set. Let's assume the box has IPv6 also, but not configured in any way in torrc.

It will guess both IPv4 and IPv6 addresses and rebuild the descriptor with the public IPv4 (and IPv6) addresses it found, complaining that "The ORPort address does not match the descriptor address", regardless this was the intended action by the operator. Then it tries self reachability test -- this later behavior is only a bug if AssumeReachable 1 is also set, otherwise it's normal. But Address should only be guessed when ORPort is not explicitly set.

I recommend:

IPv4: If ORPort is set with an explicit IP address and not just ORPort 9001, don't try to guess Address any more if it's not set for IPv4. Use only what was explicitly configured. We only try to further discover our IPv6, but don't override the IPv4 part of the descriptor if we find a different IPv4 address, or don't try to guess IPv4 address at all.
IPv6: If ORPort is set with an explicit IPv6 address don't try to guess our IPv6 address any more if it's not set in a second line for IPv6. Use what was explicitly configured. If Address is not set for IPv6, we try to guess it and if we find one, we include it in the descriptor but without overriding the IPv4 part of the descriptor.

Some thing like:

(1) ORPort 9001

behave like we do now, guess both public IPv4 and IPv6 address and build descriptor. Except don't try to self test if AssumeReachable 1 is also set and don't publish descriptor if PublishServerDescriptor 0 is also set. Also don't try to guess IPv6 if IPv4Only flag set is also set or don't try to guess IPv4 adddress if IPv6Only flag is also set -- second example not possible because currently we do not support IPv6 only relays, but this is how it should behave. IPv4Only flag is also ignored currently.

(2) ORPort 1.2.3.4:9001

Assume Address is 1.2.3.4. Don't try to discover our IPv4 address. Try to discover our IPv6 address as we do now only if IPv4Only flag was not also set. If one found, include it in the descriptor without altering the IPv4 part of the descriptor. Don't try to self test if AssumeReachable 1 is also set and don't publish descriptor if PublishServerDescriptor 0 is also set.

(3) ORPort 1.2.3.4:9001 ORPort [::1]:9001

Assume Address is 1.2.3.4 and ::1 for IPv6. Don't try to discover our IPv4 or IPv6 address. Don't try to self test if AssumeReachable 1 is also set and don't publish descriptor if PublishServerDescriptor 0 is also set.

(4) ORPort [::1]:9001

Assume Address is ::1 for IPv6. Try to guess Address for IPv4 if IPv6Only flag was not also set. If one found include it in the descriptor without altering the IPv6 part of the descriptor. Don't try to self test if AssumeReachable 1 is also set and don't publish descriptor if PublishServerDescriptor 0 is also set.

this one is not possible because we don't support IPv6 only relays currently, but this is how it should behave in such a scenario.

ORPort 1.2.3.4:9001 and Address 5.6.7.8 in the same torrc config is considered invalid config format. Same as ORPort [::1]:9001 and Address [fe80::ff:2001] also considered invalid config format. Lemme know if you need a separate issue for this.

OutboundBindAddress , OutboundBindAddressOR , OutboundBindAddressExit should not be touched by this dance, unless otherwise explicitly configured, otherwise let Tor choose as per OS preferences (like we currently do now).

Ok there is much here.

(2) -> What you describe is what is suppose to happen that is if ORPort 1.2.3.4:9001, the IPv4 discovery is not done, only the IPv6 one. If this is broken, problem which would benefit its own ticket.

(3) -> Again, what you describe is what should be happening at the moment. It is not?

(4) -> Same as above.

I have just included the correct behavior for all those cases in order to make sure we don't miss while we review the code that it actually does this. Some parts of the behavior are not broken currently of course.

However, for 2 3 and 4 yes and no. I mean, Address is taken from explicit ORPort, the problem is that when IPv6 auto discovery is done (shortly after start), if it also find a different public IPv4 address (I don't know why it looks for a v4 one in the first place) it overrides the one set in ORPort 1.2.3.4.:9001. Also, IPv4Only flag is ignored. I did not test IPv6Only flag functionality but I think it's the same case as IPv4Only.

So basically what happens is obvious -- IPv6 auto discovery triggers IPv4 auto discovery immediately and if it finds a different public IPv4 address it overrides the one used with ORPort.

On the latest master, branch without AssumeReachable 1:

Dec 01 13:13:20.000 [notice] Bootstrapped 100% (done): Done
Dec 01 13:13:20.000 [notice] Now checking whether IPv4 ORPort REDACTED:6666 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Dec 01 13:13:20.000 [notice] Now checking whether IPv6 ORPort [REDACTED]:6666 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)

With:

Dec 01 13:14:20.000 [notice] Bootstrapped 100% (done): Done

I don't see this as a bug right now. This is on FreeBSD 13.0-CURRENT (FreeBSD's equivalent to Debian Unstable/Windows Insider) on a dual-stack connection (Google Fiber/Webpass).

I don't see how this is possible. I am on Debian buster, with AssumeReachable 1 I get:

Dec 01 16:32:45.000 [notice] Now checking whether IPv4 ORPort [scrubbed]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)

Actually I have tried on two VM's. I fail to see how it is possible to have different results. I have double checked the torrc.

Ok, so I'll concentrate on fixing the AssumeReachable 1 issue and anything else should be its own ticket else I will loose track :S...

@neel , I will take this one since it is very tricky and the 045-stable deadline is approaching so we need this quickly. Hope you don't mind too much.

assigned to @dgoulet and unassigned @neel

It's fine.

Ok so I tracked down the problem and maybe not ideal but unclear. So the original behavior was that AssumeReachable 1 just skips the reachability test and publish the descriptor right away.

I've looked into 0.3.5 and that is what it does. However, it will still attempt reachability test due to the need of testing circuit which are used for various reasons.

The difference with 035 and now is that the log notice is triggered when the testing circuit is launched which was not before in 035. In theory, they both have the same behavior just the log notice is wrong.

It is unfortunate that those two things as in reachability test and testing circuits are intertwined like this, it is a bit messy code so I expect history took over :P.

What I think I can do is only print the log notice if we actually trying to do an ORPort reachability that is our ORPort was is considered not reachable. Oh and also avoid triggering a control event of "checking reachability".

mentioned in merge request !235 (closed)

In theory yes, but after many of these messages such a relay or bridge will stop working because it won't upload a fresh descriptor.

So, you start, it warns heavily about how it is trying to do a self reachability test, but it works (as a relay or bridge for other client) for some time. After some time it stops working for the client but the relay/bridge Tor process does not die or warn anything unusual, just continues the self reachability attempts.

The current message is very good and useful for when AssumeReachable 1 is not set, I don't think it's a good idea to change it for those cases, just to differentiate if the test was triggered by the need of a testing circuit or ORPort reachability and adjust the messages as per each case. Obviously AssumeReachable 1 should be a quite less popular setup.

mentioned in commit e74f168b

closed with commit e74f168b

Our IPv6 Autodiscovery breaks AssumeReachable 1 torrc option

Child items ...

Activity