[guardian-dev] IPtProxy snowflake proxies (kindness mode) frequently self-measure "unknown" NAT type?
David Fifield
david at bamsoftware.com
Thu Sep 19 14:36:31 EDT 2024
It shouldn't matter, I don't think. It's unexpected to have so many
"unknown" results, rather than resolving into "restricted" or
"unrestricted". Even if most of the Orbot proxies are on restricted NAT,
we would expect the NAT type test to come up "restricted" rather than
"unknown", when everything is working correctly.
There was some discussion at the team meeting today that said it may be
relevant if the Orbot proxy overwrites a previous "restricted" or
"unrestricted" result with an "unknown" in repeated tests.
https://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-09-19-16.00.log.html
<shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40387#note_3079668
<dcf1> shelikhoo: why would tpo/anti-censorship/pluggable-transports/snowflake#40387 have a disproportionate effect on iptproxy and not other proxy types?
<shelikhoo> As for the difference impact for different proxy implantation, one possibility is about how unknown result is process; some will just let it overwrite last result, others might retain the last result
<shelikhoo> in standalone proxy, it retain last result if the most recent nat test's result is unknown
<WofWca[m]> The Go lib never goes from a known type to "unknown" AFAIK
<WofWca[m]> Even when probetest fails
<shelikhoo> yes, so it will tolerate more failure of the nat type testing process
<cohosh> i do think iptproxy should change how they configure their proxy stun servers regardless
<cohosh> but it would help answer as to whether that's what's causing issues here
<cohosh> because i would have expected it to result in more restricted NATs than necessary rather than more unknowns but it's been a while since I looked at this
On Sat, Sep 14, 2024 at 10:33:56AM -0400, Nathan of Guardian wrote:
> Could it be that Orbot Snowflake proxies are often running on mobile operator WAN networks as opposed to fixed line / home infrastructure?
>
> On Fri, Sep 13, 2024, at 10:33 PM, David Fifield wrote:
> > WofWca has been investigating why so many snowflake proxies (about half)
> > report the "unknown" NAT type (meaning that the NAT type self-test
> > failed somehow). Here's background on NAT type self-testing; note that
> > "unknown" gets treated as "restricted" which limits what snowflake
> > clients may be served:
> > https://www.bamsoftware.com/papers/snowflake/#connection
> >
> > The surprising is that almost all of the "unknown" NAT types are
> > IPtProxy proxies; i.e. Orbot. While other other proxy types have a
> > maximum of around 4% "unknown", IPtProxy is at 47% "unknown".
> >
> > https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40384#note_3077291
> >
> >> I looked at [broker Prometheus metrics](https://snowflake-broker.torproject.net/prometheus)
> >> and here are NAT type percentages per proxy type:
> >>
> >> | % of NAT type per category | badge | iptproxy | standalone | webext |
> >> |----------------------------|---------|-----------|-------------|--------|
> >> | restricted | 100,00% | 52,95% | 85,24% | 95,90% |
> >> | unknown | 0,00% | 47,02% | 2,51% | 3,92% |
> >> | unrestricted | 0,00% | 0,03% | 12,25% | 0,18% |
> >>
> >> As we can see, iptproxy (Orbot) has a very high percentage of
> >> "unknown" NAT type. As I said, the Go version of Snowflake, which is
> >> used in iPtProxy, does not start doing poll requests until the NAT
> >> check has been completed (or has failed).
> >
> > This is just a heads up to see if anyone on the Orbot team happens to
> > know a possible cause offhand.
More information about the guardian-dev
mailing list