Opened 7 weeks ago

Last modified 2 weeks ago

#31542 assigned defect

Cannot connect to IPv6 addresses using Tor SOCKS

Reported by: sega01 Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.4.0.5
Severity: Normal Keywords: ipv6
Cc: Actual Points:
Parent ID: #26664 Points:
Reviewer: Sponsor:

Description

Here is my Tor configuration:

SocksPort 127.0.0.1:9050 IPv6Traffic
SocksPort [::1]:9050 IPv6Traffic
DataDirectory /run/tor_client
ControlPort unix:/run/tor_client/control
ClientUseIPv6 1

I'm using 0.4.1.5 on Debian 9.

IPv4 direct addresses are fine:

$ curl -s -x socks5h://127.0.0.1:9050 -v 157.230.170.226
* Rebuilt URL to: 157.230.170.226/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to 157.230.170.226:80
* SOCKS5 request granted.
* Connected to (nil) (127.0.0.1) port 9050 (#0)
> GET / HTTP/1.1
> Host: 157.230.170.226
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Tue, 27 Aug 2019 20:54:51 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://157.230.170.226/
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host 157.230.170.226 left intact
$ curl -s -x socks5h://[::1]:9050 -v 157.230.170.226
* Rebuilt URL to: 157.230.170.226/
*   Trying ::1...
* TCP_NODELAY set
* SOCKS5 communication to 157.230.170.226:80
* SOCKS5 request granted.
* Connected to (nil) (::1) port 9050 (#0)
> GET / HTTP/1.1
> Host: 157.230.170.226
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Tue, 27 Aug 2019 20:55:03 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://157.230.170.226/
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host 157.230.170.226 left intact

IPv6 direct addresses do not work:

$ curl -s -x socks5h://[::1]:9050 -v [2604:a880:cad:d0::684e:f001]
* Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
*   Trying ::1...
* TCP_NODELAY set
* SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
* Can't complete SOCKS5 connection to 0000:0000:0000:0000:0000:0000:0000:0000:0. (1)
* Closing connection 0
$ curl -s -x socks5h://127.0.0.1:9050 -v [2604:a880:cad:d0::684e:f001]
* Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
* Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
* Closing connection 0

What should I test from here?

Thanks!

Child Tickets

Change History (13)

comment:1 Changed 7 weeks ago by sega01

I am also seeing this behavior with Tor Browser 8.5.4.

comment:2 Changed 7 weeks ago by teor

Keywords: 042-should 041-regression? ipv6 added
Milestone: Tor: 0.4.2.x-final
Status: newneeds_information

Can you copy and paste your notice level Tor logs for the IPv6 failures?

What is the last tor version that worked with IPv6?
0.4.0, 0.3.5, or 0.2.9?

comment:3 Changed 7 weeks ago by sega01

Thanks for getting back to me!

There were no notice logs generated (mind you, with my configuration but I think I normally get those) from the Tor client.

I am not sure which one worked last. That said, I know 4.0.5 has the same issue. And 4.0.5 and 4.1.5 both work fine with IPv6 using TransPort.

comment:4 Changed 7 weeks ago by teor

Keywords: 041-regression? removed

What are your log configuration lines?

There should be notice level logs for connection failures.
But some logs are at info level.
Can you copy and paste info-level logs from these failures?

Do 0.3.5 or 0.2.9 have this bug?

I'll open a child ticket, so we add tests to make sure 5is issue doesn't happen again.

comment:5 Changed 7 weeks ago by sega01

At the top of my ticket I have my complete configuration.

If I add "Log notice stderr", I get nothing extra when I try to connect.

If I add "Log info stderr", I get this.

Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] connection_handle_listener_read(): New SOCKS connection opened from [::1].
Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] add_predicted_port(): New port prediction added. Will continue predictive circ building for 2619 more seconds.
Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] exit circ (length 3): $AF9E103026FBCB20179233D293C4982665D2A01C(open) $4E98AA295B7171996D18DD1F6A19F64AB4036B4A(open) $96E095D5CDBFC3988DEB708EC155346472402C32(open)
Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] link_apconn_to_circ(): Looks like completed circuit to [scrubbed] does allow optimistic data for connection to [scrubbed]
Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] connection_ap_handshake_send_begin(): Sending relay cell 0 on circ 3481194959 to begin stream 48431.
Aug 28 05:03:10 red_identity_vm tor[27186]: Aug 28 05:03:10.000 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket 16, n_circ_id 3481194959
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] circuit_predict_and_launch_new(): Have 7 clean circs need another buildtime test circ.
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] choose_good_exit_server_general(): Found 992 servers that might support 0/0 pending connections.
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as exit
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] choose_good_exit_server_general(): Chose exit server '$6FB41ED1D68FCC399DCE81600CE30360DCFFE263~Unnamed at 62.210.37.82'
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] extend_info_from_node(): Including Ed25519 ID for $6FB41ED1D68FCC399DCE81600CE30360DCFFE263~Unnamed at 62.210.37.82
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] select_primary_guard_for_circuit(): Selected primary guard zwiuhel ($AF9E103026FBCB20179233D293C4982665D2A01C) for circuit.
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] extend_info_from_node(): Including Ed25519 ID for $AF9E103026FBCB20179233D293C4982665D2A01C~zwiuhel at 95.216.203.16
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] extend_info_from_node(): Including Ed25519 ID for $E6C04728E9339DF22F331B7017D4A7AA3F252F0B~malekalcom at 149.202.208.203
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] circuit_send_first_onion_skin(): First hop: finished sending CREATE cell to '$AF9E103026FBCB20179233D293C4982665D2A01C~zwiuhel at 95.216.203.16'
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] command_process_relay_cell(): circuit_receive_relay_cell (backward) failed. Closing.
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] circuit_mark_for_close_(): Circuit 3481194959 (id: 12) marked for close at ../src/core/or/command.c:582 (orig reason: 1, new reason: 0)
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] connection_edge_destroy(): CircID 0: At an edge. Marking connection for close.
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] circuit_free_(): Circuit 0 (id: 12) has been freed.
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] circuit_finish_handshake(): Finished building circuit hop:
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] exit circ (length 3, last hop Unnamed): $AF9E103026FBCB20179233D293C4982665D2A01C(open) $E6C04728E9339DF22F331B7017D4A7AA3F252F0B(closed) $6FB41ED1D68FCC399DCE81600CE30360DCFFE263(closed)
Aug 28 05:03:11 red_identity_vm tor[27186]: Aug 28 05:03:11.000 [info] circuit_send_intermediate_onion_skin(): Sending extend relay cell.
Aug 28 05:03:12 red_identity_vm tor[27186]: Aug 28 05:03:12.000 [info] entry_guard_inc_circ_attempt_count(): Got success count 8.000000/9.000000 for guard zwiuhel ($AF9E103026FBCB20179233D293C4982665D2A01C)
Aug 28 05:03:12 red_identity_vm tor[27186]: Aug 28 05:03:12.000 [info] circuit_finish_handshake(): Finished building circuit hop:
Aug 28 05:03:12 red_identity_vm tor[27186]: Aug 28 05:03:12.000 [info] exit circ (length 3, last hop Unnamed): $AF9E103026FBCB20179233D293C4982665D2A01C(open) $E6C04728E9339DF22F331B7017D4A7AA3F252F0B(open) $6FB41ED1D68FCC399DCE81600CE30360DCFFE263(closed)
Aug 28 05:03:12 red_identity_vm tor[27186]: Aug 28 05:03:12.000 [info] circuit_send_intermediate_onion_skin(): Sending extend relay cell.
Aug 28 05:03:13 red_identity_vm tor[27186]: Aug 28 05:03:13.000 [info] circuit_finish_handshake(): Finished building circuit hop:
Aug 28 05:03:13 red_identity_vm tor[27186]: Aug 28 05:03:13.000 [info] exit circ (length 3, last hop Unnamed): $AF9E103026FBCB20179233D293C4982665D2A01C(open) $E6C04728E9339DF22F331B7017D4A7AA3F252F0B(open) $6FB41ED1D68FCC399DCE81600CE30360DCFFE263(open)
Aug 28 05:03:13 red_identity_vm tor[27186]: Aug 28 05:03:13.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard zwiuhel ($AF9E103026FBCB20179233D293C4982665D2A01C)
Aug 28 05:03:13 red_identity_vm tor[27186]: Aug 28 05:03:13.000 [info] circuit_build_no_more_hops(): circuit built!
Aug 28 05:03:13 red_identity_vm tor[27186]: Aug 28 05:03:13.000 [info] pathbias_count_build_success(): Got success count 9.000000/9.000000 for guard zwiuhel ($AF9E103026FBCB20179233D293C4982665D2A01C)

I'm sure I have some extraneous stuff in there. You can see the SOCKS connection but I didn't notice anything useful. I don't think Tor thinks it's broken in any way.

I am not sure yet on 0.3.5 or 0.2.9.

Can someone else reproduce this? I wonder if there's something weird where my IPv6Traffic option for SocksPort is somehow causing an issue.

comment:6 Changed 7 weeks ago by teor

I can't see anything obvious, but the exit does seem to be closing the connection.

Try connecting to the same IPv6 address a few times.
Only 20% of the exits support IPv6, and Tor will try 3 exits.
So raw IPv6 will fail about half the time.

Also try setting PreferIPv6 on your SOCKSPort:

IPv6Traffic

Tell exits to allow IPv6 addresses in response to SOCKS requests on this connection, so long as SOCKS5 is in use. (SOCKS4 can’t handle IPv6.)

PreferIPv6

Tells exits that, if a host has both an IPv4 and an IPv6 address, we would prefer to connect to it via IPv6. (IPv4 is the default.)

https://2019.www.torproject.org/docs/tor-manual.html.en

Last edited 7 weeks ago by teor (previous) (diff)

comment:7 Changed 7 weeks ago by sega01

There were a ton of logs going on even without trying to generate activity, maybe from other connections (although I didn't think I had anything using it). I think most of those logs had nothing to do with this issue (and it was also connecting over Tor already, so that may be partly why).

The issue with part-time IPv6 working (one in 20%) is with DNS. With the TransPort/iptables setup, IPv6 basically works 100% of the time for me. But I get maybe 20% of DNS to IPv6 only requests to go through.

I did about 10 with PreferIPv6 and IPv6Traffic on. None of them worked.

If I hit an IPv6 only hostname, it will work maybe 20% of the time. So IPv6 isn't totally broken, even over SOCKS.

comment:8 Changed 7 weeks ago by teor

Parent ID: #26664
Status: needs_informationnew

Yeah, there's definitely some bug here, see the children of #26664 for similar bugs.

I've put #26664 on our IPv6 roadmap.

comment:9 Changed 7 weeks ago by sega01

Great, thank you! Let me know if you need anything else from me.

comment:10 Changed 2 weeks ago by ahf

Owner: set to asn
Status: newassigned

Distributing 0.4.2 tickets between network team members.

comment:11 Changed 2 weeks ago by asn

Status: assignedneeds_information

Tim, I checked the children of #26664 and they seem quite related to this ticket. Is there a bug present in this ticket that is not filed under #26664 that we are looking for? Or will fixing the children of #26664 (e.g. #24833) also fix this bug?

comment:12 Changed 2 weeks ago by teor

Keywords: 042-can added; 042-should removed
Status: needs_informationnew

If this bug existed in 0.4.0 and 0.4.1, it's not new. So there is unlikely to be a quick fix. And we don't need to fix it in 0.4.2.

comment:13 Changed 2 weeks ago by teor

Keywords: 042-can removed
Milestone: Tor: 0.4.2.x-finalTor: unspecified
Owner: asn deleted
Status: newassigned
Version: Tor: 0.4.1.5Tor: 0.4.0.5
Note: See TracTickets for help on using tickets.