Opened 8 years ago

Closed 6 years ago

#2267 closed defect (fixed)

resolve_my_address() resolves incorrect address.

Reported by: eric225125 Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have tried tor 0.2.1.26, 0.2.1.27, and 0.2.2.19-alpha. They all detect my IP address as either 8.15.7.117 or 63.251.179.13. Neither is correct. Every 10 minutes or so, tor will switch between the two incorrect IP addresses. Tor seems to be working correctly has a client, but not as a relay. I have set the correct Address in my torrc, and then tor displays the correct address, but is not any more functional.

My network is pretty standard. I am behind a NAT router, but all ports are forwarded to my computer running tor. Other networking programs like bittorrent, edonkey, and freenet all work correctly. Nothing interesting shows up in the logs.

Child Tickets

Change History (25)

comment:1 Changed 8 years ago by eric225125

It seems this problem is related to my DNS server. The two incorrect IP addresses are somehow resolved from my ISP's server. I tried OpenDNS's and had the same problem. After switching to another DNS server from my ISP, my IP address is correctly resolved.

This is the message I get with the bad DNS servers:
Dec 08 16:52:15.401 [notice] Your DNS provider has given "67.215.65.132" as an answer for 11 different invalid ad
dresses. Apparently they are hijacking DNS failures. I'll try to correct for this by treating future occurrences
of "67.215.65.132" as 'not found'.

I had thought this was harmless, but I guess not.

comment:2 Changed 8 years ago by rransom

boboper points out that resolve_my_address tries to resolve the system's hostname using tor_lookup_hostname, which uses the system's gethostbyname function, and in this case, the request was sent to the DNS server, not processed locally.

What operating system are you using?

comment:3 Changed 8 years ago by Myshkin

I am having somewhat the same problem. TOR is functional but I can't set it up as a relay as ORPort and DIRPort will now work. I recently upgraded my system to a higher bandwidth which required changing the IP address in my router. TOR now tells me that ORPort and DIRPort should open on IP 216.220.113.37. My actual IP is 192.168.1.102 and the DNS servers are 216.220.96.17 and .18. How can I fix this?

comment:4 in reply to:  3 Changed 8 years ago by rransom

Replying to Myshkin:

I am having somewhat the same problem. TOR is functional but I can't set it up as a relay as ORPort and DIRPort will now work. I recently upgraded my system to a higher bandwidth which required changing the IP address in my router. TOR now tells me that ORPort and DIRPort should open on IP 216.220.113.37. My actual IP is 192.168.1.102 and the DNS servers are 216.220.96.17 and .18. How can I fix this?

Switch to Google's DNS servers (8.8.8.8 and 8.8.4.4).

What operating system are you using?

comment:5 Changed 8 years ago by Sebastian

The google dns suggestion is unlikely to help here, I think Myshkin is probably just a bit confused about private IP addresses. Your actual IP is 192.168.1.102 on your local network only, on the internet you will have a different IP (and 216.220.113.37 is likely to be the correct one as indicated by the same prefix as compared to the dns server). The issue is more likely port forwarding here.

comment:6 in reply to:  3 Changed 8 years ago by rransom

Replying to Myshkin:

I am having somewhat the same problem. TOR is functional but I can't set it up as a relay as ORPort and DIRPort will now work. I recently upgraded my system to a higher bandwidth which required changing the IP address in my router. TOR now tells me that ORPort and DIRPort should open on IP 216.220.113.37. My actual IP is 192.168.1.102 and the DNS servers are 216.220.96.17 and .18. How can I fix this?

Sebastian is right -- 216.220.113.37 is a home router/firewall, and is currently exposing a web-based configuration interface to the Internet on port 80, along with several other configuration interfaces. Please turn off the external configuration interfaces.

comment:7 Changed 8 years ago by eric225125

Sorry, I forgot to update this ticket. It turns out the source of my problem was that I forgot to set my local hostname in my hosts file to 127.0.0.1, so tor was looking it up with my dns, and my bad ISP dns was returning a bad IP. A good dns failed the hostname lookup even when it wasn't defined. After defining my hostname in my hosts file, all dns worked.

comment:8 Changed 8 years ago by nickm

Milestone: Tor: unspecified

Shall we close as notabug, or add some more log messages to communicate better how we decided what address to publish?

comment:9 Changed 7 years ago by Sebastian

Resolution: not a bug
Status: newclosed

comment:10 Changed 7 years ago by rransom

Resolution: not a bug
Status: closedreopened

We had another report of this recently in #tor. Something must be done.

comment:11 Changed 7 years ago by nickm

Something must be done.

Any suggestions of what?

comment:12 in reply to:  11 ; Changed 7 years ago by rransom

Replying to nickm:

Something must be done.

Any suggestions of what?

velope wants a log message, saying what hostname Tor resolved and what IP address it resolved to.

I want (a) a flag which indicates that Tor learned its external IP address by resolving its hostname, (b) a flag that tells Tor to not try to learn its external IP address by resolving its hostname, and (c) a routine (called when Tor has learned its external IP address by resolving its hostname and Tor has detected that its DNS servers lie) that checks whether Tor's external IP address matches an address used for DNS hijacking, and, if so, sets the ‘don't learn your address from your lying DNS servers’ flag and causes Tor to try to determine its IP address again.

comment:13 in reply to:  12 Changed 7 years ago by nickm

Replying to rransom:

Replying to nickm:

Something must be done.

Any suggestions of what?

velope wants a log message, saying what hostname Tor resolved and what IP address it resolved to.

I want (a) a flag which indicates that Tor learned its external IP address by resolving its hostname, (b) a flag that tells Tor to not try to learn its external IP address by resolving its hostname, and (c) a routine (called when Tor has learned its external IP address by resolving its hostname and Tor has detected that its DNS servers lie) that checks whether Tor's external IP address matches an address used for DNS hijacking, and, if so, sets the ‘don't learn your address from your lying DNS servers’ flag and causes Tor to try to determine its IP address again.

I think that velope's idea should be really doable for 0.2.3.x. I like your idea too, but it feels more like an 0.2.4.x thing to me.

comment:14 Changed 7 years ago by arma

See bug2267a in my git repo for a better log message.

comment:15 Changed 7 years ago by arma

Also, I notice that resolve_my_address() can call get_interface_address(). If that's how it learned it, it sure is misleading for check_descriptor_ipaddress_changed() to pass "source: resolve" to log_addr_has_changed().

comment:16 Changed 7 years ago by nickm

Status: reopenedneeds_revision

arma: your bug2267a looks like an improvement, but needs a changes file. Also, the comment you made about get_interface_address() seems correct; we shouldn't log "resolved from foo" when that happens.

comment:17 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:18 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:19 Changed 6 years ago by arma

Status: needs_revisionneeds_review

See my bug2267b branch.

In particular, be sure to fix the "const char method_out" part as needed, since I never quite put my consts in the right places.

This branch also fixes #8200.

comment:20 Changed 6 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.4.x-final

d3695ea0ad04e looks good.

In the other commit (d8f3a49060d), where you log "METHOD=%s %s%s), there's going to be an extra space sometimes. That'll be easy to fix.

The call to resolve_my_address in check_descriptor_ipaddress_changed() didn't get a "if (!hostname) hostname = tor_dup_ip(addr)" like the other calls did. Should it?

comment:21 in reply to:  20 ; Changed 6 years ago by nickm

Replying to nickm:

d3695ea0ad04e looks good.

In the other commit (d8f3a49060d), where you log "METHOD=%s %s%s), there's going to be an extra space sometimes. That'll be easy to fix.

The call to resolve_my_address in check_descriptor_ipaddress_changed() didn't get a "if (!hostname) hostname = tor_dup_ip(addr)" like the other calls did. Should it?

Oh, nevermind: hostname was NULL there.

comment:22 in reply to:  21 Changed 6 years ago by nickm

Replying to nickm:the other calls did. Should it?

Oh, nevermind: hostname was NULL there.

Wait; apparently not. But we are, I guess, checking for whether hostname is NULL a bit later on.

comment:23 Changed 6 years ago by nickm

See "bug2267b" in my public repository for the minor tweak. Other than that, IMO, it's good to go.

comment:24 in reply to:  23 Changed 6 years ago by arma

Replying to nickm:

See "bug2267b" in my public repository for the minor tweak. Other than that, IMO, it's good to go.

Looks good to me. Thanks!

(This patch will result in several log lines with a lot of redundant information between them, when your IP address changes. That's something we can clean up in 0.2.5 or something if it bothers us.)

comment:25 Changed 6 years ago by arma

Resolution: fixed
Status: needs_reviewclosed

Merged. And closing #8200 too.

Note: See TracTickets for help on using tickets.