[tor-bugs] #23257 [Obfuscation/Snowflake]: Snowflake doesn't connect on the CalVisitor network

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Aug 16 21:15:51 UTC 2017


#23257: Snowflake doesn't connect on the CalVisitor network
---------------------------------------+--------------------
     Reporter:  dcf                    |      Owner:  (none)
         Type:  defect                 |     Status:  new
     Priority:  Medium                 |  Milestone:
    Component:  Obfuscation/Snowflake  |    Version:
     Severity:  Normal                 |   Keywords:
Actual Points:                         |  Parent ID:
       Points:                         |   Reviewer:
      Sponsor:                         |
---------------------------------------+--------------------
 Snowflake doesn't work on [https://telecom.berkeley.edu/calvisitor one of
 the wireless networks] at UC Berkeley. It sends an offer and receives an
 answer, but then hangs here:
 {{{
 2017/08/16 13:56:38 ---- Handler: snowflake assigned ----
 2017/08/16 13:56:38 Buffered 203 bytes --> WebRTC
 2017/08/16 13:56:43 Traffic Bytes (in|out): 0 | 203 -- (0 OnMessages, 1
 Sends)
 }}}

 I initially suspected that it had something to do with the network not
 assigning a public IPv4 address, only a public IPv6 address. I moved our
 existing proxy-go instances to a host with an IPv6 address, and that
 didn't help.

 Here's the part of the log where client gathers its candidates. Notice the
 IPv6 address 2607:f140:6000:2:c53e:4d3e:19d5:d94c and the IPv4 address
 10.105.136.190.
 {{{
 2017/08/16 13:55:58 WebRTC: DataChannel created.
 2017/08/16 13:55:58 candidate:1109156821 1 udp 2122262783
 2607:f140:6000:2:c53e:4d3e:19d5:d94c 56748 typ host generation 0 ufrag
 3h4p network-id 2 network-cost 50
 2017/08/16 13:55:58 candidate:2027054270 1 udp 2122194687 10.105.136.190
 61395 typ host generation 0 ufrag 3h4p network-id 1 network-cost 50
 2017/08/16 13:55:58 candidate:211787557 1 tcp 1518283007
 2607:f140:6000:2:c53e:4d3e:19d5:d94c 49259 typ host tcptype passive
 generation 0 ufrag 3h4p network-id 2 network-cost 50
 2017/08/16 13:55:58 candidate:911317070 1 tcp 1518214911 10.105.136.190
 49260 typ host tcptype passive generation 0 ufrag 3h4p network-id 1
 network-cost 50
 2017/08/16 13:55:59 SOCKS accepted:  {0.0.3.0:1  map[]}
 }}}

 Here's an abridged form of the answer. Notice how the candidates
 (`a=candidate:`) include both IPv6 2a00:c6c0:0:151:4:8f94:69f5:7c01 and
 IPv4 37.218.242.151. However, the connection address (`c=`) is the IPv4
 address.
 {{{
 o=- 5000276783403536546 2 IN IP4 127.0.0.1
 m=application 41242 DTLS/SCTP 5000
 c=IN IP4 37.218.242.151
 a=candidate:836092752 1 udp 2122262783 2a00:c6c0:0:151:4:8f94:69f5:7c01
 40571 typ host generation 0 network-id 1 network-cost 50
 a=candidate:404726760 1 udp 2122194687 37.218.242.151 41242 typ host
 generation 0 network-id 2 network-cost 50
 a=candidate:2136358816 1 tcp 1518283007 2a00:c6c0:0:151:4:8f94:69f5:7c01
 39103 typ host tcptype passive generation 0 network-id 1 network-cost 50
 a=candidate:1453088536 1 tcp 1518214911 37.218.242.151 49703 typ host
 tcptype passive generation 0 network-id 2 network-cost 50
 }}}

 Is this one of those weird NAT cases where a TURN server is needed? Is
 that why it's not working? The CalVisitor does block some applications
 like IMAP.

 I tested this with Tor Browser 7.5a4 for mac.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23257>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list