Opened 4 years ago

Closed 4 years ago

#18819 closed defect (duplicate)

ORPort listening on one IP, but advertising on another

Reported by: reezer Owned by:
Priority: Very High Milestone:
Component: Core Tor/Tor Version: Tor: 0.2.7.6
Severity: Major Keywords: 029-proposed
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I tell Tor to listen on one IP it (according to the log) still advertises itself on a different IP.

I am running the following configuration. The only change are the x's on IPs. Nothing else was removed or changed. See how the IP ends with .81.

SocksPort 0
ORPort x.x.x.81:33075
BridgeRelay 1
Exitpolicy reject *:*
User _tor

Nickname xxx
ContactInfo xxx

# Logging
Log notice file /var/log/tor.log

# Enable the Extended ORPort
ExtORPort auto
ServerTransportPlugin obfs3 exec xxx/bin/obfs4proxy
ServerTransportPlugin obfs4 exec xxx/bin/obfs4proxy

ServerTransportListenAddr obfs3 x.x.x.81:33074
ServerTransportListenAddr obfs4 x.x.x.81:443

When starting Tor (nothing but status lines that have been replaced with ... removed) it correctly outputs the listening ip, but still advertises on another ip (.81 vs .172).

Apr 14 11:06:58.110 [notice] Tor v0.2.7.6 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
...
Apr 14 11:06:58.135 [notice] Opening OR listener on x.x.x.81:33075
Apr 14 11:06:58.135 [notice] Opening Extended OR listener on 127.0.0.1:0
Apr 14 11:06:58.136 [notice] Extended OR listener listening on port 22692.
...
Apr 14 11:06:59.000 [notice] Bootstrapped 0%: Starting
Apr 14 11:07:00.000 [notice] Bootstrapped 5%: Connecting to directory server
Apr 14 11:07:35.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Apr 14 11:07:35.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 14 11:07:36.000 [notice] Registered server transport 'obfs3' at 'x.x.x.81:33074'
Apr 14 11:07:36.000 [notice] Registered server transport 'obfs4' at 'x.x.x.81:443'
Apr 14 11:07:37.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 14 11:07:37.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 14 11:07:37.000 [notice] Bootstrapped 100%: Done
Apr 14 11:07:37.000 [notice] Now checking whether ORPort x.x.x.172:33075 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)

ifconfig output. See how the interface has two IP addresses. Tor appears to be looking at the first one for advertisement, despite ORPort being set to the second one.

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether xx:xx:xx:xx:xx:x
        inet x.x.x.172 netmask 0xffffff00 broadcast x.x.x.255 
        inet x.x.x.81 netmask 0xffffff00 broadcast x.x.x.255

sockstat (similar to netstat) output:

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
_tor     tor        12580 5  tcp4   x.x.x.81:33075   *:*

Command Line:

/usr/local/bin/tor -f /usr/local/etc/tor/torrc --PidFile /var/run/tor/tor.pid --RunAsDaemon 1 --DataDirectory /var/db/tor

Also Tor isn't running in a jail and there is nothing else I can think of affecting it.

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by reezer

Summary: ORPort listening on one IP, but listening on anotherORPort listening on one IP, but advertising on another

comment:2 Changed 4 years ago by dgoulet

Keywords: 029-proposed added
Priority: MediumHigh
Severity: NormalMajor

From the sockstat command we can see that it's on the right IP but the ORPort testing using the wrong IP is the one that concerns me:

Apr 14 11:07:37.000 [notice] Now checking whether ORPort x.x.x.172:33075 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)

I would be curious to know also what IP is in the consensus. Is it the right IP when you check your relay in https://globe.torproject.org?

comment:3 Changed 4 years ago by reezer

That's hard to find out. It's configured as a bridge. Also it's not published I think, because the ORPort will never become reachable.

That might indicate that it is the wrong on though?

Last edited 4 years ago by reezer (previous) (diff)

comment:4 in reply to:  3 Changed 4 years ago by dgoulet

Priority: HighVery High

Replying to reezer:

That's hard to find out. It's configured as a bridge. Also it's not published I think, because the ORPort will never become reachable.

That might indicate that it is the wrong on though?

Indeed, that means tor tries the _wrong_ IP for ORPort testing... Ok, I'll try to reproduce in a jiffy but in the meantime I'm setting this one to a higher priority since this one can have all sorts of consequences.

comment:5 Changed 4 years ago by teor

This is a duplicate of #13953. Please set the torrc option 'Address'.

comment:6 Changed 4 years ago by reezer

Setting Address indeed causes the correct address to be used.

comment:7 Changed 4 years ago by dgoulet

Resolution: duplicate
Status: newclosed

Oh... a workaround exists! Let's close this one then and move all other discussions to the original bug (#13953).

Note: See TracTickets for help on using tickets.