[tor-bugs] #34129 [Circumvention/Snowflake]: Use STUN to determine NAT behaviour of peers

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu May 21 17:36:21 UTC 2020


#34129: Use STUN to determine NAT behaviour of peers
-------------------------------------+---------------------------
 Reporter:  cohosh                   |          Owner:  cohosh
     Type:  enhancement              |         Status:  assigned
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:  Sponsor28
-------------------------------------+---------------------------

Comment (by cohosh):

 Replying to [comment:7 dcf]:
 > I did `apt install coturn` to use the
 [https://github.com/coturn/coturn/wiki/turnutils_stunclient
 turnutils_stunclient] program. I ran it and got the following output. I
 changed my actual IP address to `192.0.2.3`.
 >
 > {{{
 > $ turnutils_stunclient -f 174.138.112.125
 >
 > ========================================
 > RFC 5780 response 1
 > 0: IPv4. Response origin: : 10.20.0.7:3478
 > 0: IPv4. Other addr: : 68.183.200.83:3479
 > 0: IPv4. UDP reflexive addr: 192.0.2.3:32960
 > }}}
 >
 > turnutils_stunclient then hangs until I ctrl-C it.
 >
 > Looking at a packet capture, there are 2 outgoing packets and 1 incoming
 packet.
 I just tried this myself and got the same thing. It also when I tried
 other STUN servers that advertize the `OTHER-ADDRESS` attribute. I wonder
 if this is a bug in the coturn server (or at the very least the set up
 instructions).

 From reading RFC 5780, the `CHANGE-REQUEST` attribute is used to determine
 the type of NAT '''filtering''', and is not needed for determining the
 type of NAT mapping, but of course both are important to know.

 Also, now that I'm looking at this. It seems there's a typo here in the
 advertized attribute from the client. I think it should be `CHANGE-
 REQUEST`, not `CHANGE_REQUEST`. That might be causing problems.

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


More information about the tor-bugs mailing list