Standalone snowflake proxy re-testing as restricted
Hey there, I have been running a standalone snowflake proxy for quite some time now. First in a docker container, but now in its own linux container to have more control over it myself. This has worked out great so far with an ephemeral-ports-range of 200 ports. Those are forwarded to the linux container in my router. Since a few days, I noticed a big drop in connections per hour. I restarted the proxy and it tested as restricted even though all ports are properly forwarded and I see the UDP packets reaching the machine via tcpdump. After several restarts, I finally got it to confirm unrestricted but 6 hours later (default re-test period?), its restricted again. Just to rule out the obvious, is it only me having this problem? I'm building from source and git log says: commit f940d7d6efe423c4d7a901a33d34bb51086b4a41 Date: Tue Nov 26 16:19:49 2024 +0000 chore(deps): update module github.com/pion/ice/v4 to v4.0.3 I wonder if this is a problem of my local setup or a bug snowflake itself. Any ideas? Best regards, 0x5fcfbd30
We've had several reports about the NAT check being inconsistent since we upgraded and re-installed the Snowflake broker[0], it seems it's not just you having this problem. I've opened an issue to look into it[1]. Thanks for reaching out about this. [0] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... On 2024-11-29 08:56, 0x5fcfbd30--- via tor-relays wrote:
Hey there,
I have been running a standalone snowflake proxy for quite some time now. First in a docker container, but now in its own linux container to have more control over it myself. This has worked out great so far with an ephemeral-ports-range of 200 ports. Those are forwarded to the linux container in my router.
Since a few days, I noticed a big drop in connections per hour. I restarted the proxy and it tested as restricted even though all ports are properly forwarded and I see the UDP packets reaching the machine via tcpdump. After several restarts, I finally got it to confirm unrestricted but 6 hours later (default re-test period?), its restricted again.
Just to rule out the obvious, is it only me having this problem? I'm building from source and git log says:
commit f940d7d6efe423c4d7a901a33d34bb51086b4a41 Date: Tue Nov 26 16:19:49 2024 +0000 chore(deps): update module github.com/pion/ice/v4 to v4.0.3
I wonder if this is a problem of my local setup or a bug snowflake itself. Any ideas?
Best regards, 0x5fcfbd30 _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Cecylia Bocovich wrote:
We've had several reports about the NAT check being inconsistent since we upgraded and re-installed the Snowflake broker[0], it seems it's not just you having this problem. I've opened an issue to look into it[1].
Thanks for the confirmation. Meanwhile, I was getting verbose logging while doing several restarts. Most of them ended up in a timeout waiting for the probe test to open a data channel: 2024/11/29 19:29:48 Waiting for a test WebRTC connection with NAT check probe server to establish... 2024/11/29 19:29:48 NAT check: WebRTC: OnConnectionStateChange: connecting 2024/11/29 19:29:49 NAT check: WebRTC: OnConnectionStateChange: connected 2024/11/29 19:29:49 WebRTC: DataChannel.OnClose 2024/11/29 19:29:49 NAT check: WebRTC: OnConnectionStateChange: closed while a successful attempt logs like that: 2024/11/29 19:16:38 Waiting for a test WebRTC connection with NAT check probe server to establish... 2024/11/29 19:16:38 NAT check: WebRTC: OnConnectionStateChange: connecting 2024/11/29 19:16:39 NAT check: WebRTC: OnConnectionStateChange: connected *2024/11/29 19:16:39 WebRTC: DataChannel.OnOpen* 2024/11/29 19:16:39 Test WebRTC connection with NAT check probe server established! This means our NAT is unrestricted! 2024/11/29 19:16:39 NAT Type measurement: unknown -> unrestricted 2024/11/29 19:16:39 WebRTC: DataChannel.OnClose 2024/11/29 19:16:39 NAT type: unrestricted 2024/11/29 19:16:39 NAT check: WebRTC: OnConnectionStateChange: closed To me this looks like webRTC connection is successful, however, DataChannel never reaches the OnOpen but straight the OnClose signal. Looking through the proxy code, I have no idea, why that could happen, but I'm by no means an expert in WebRTC. Anyway, I hope it helps to diagnose the problem further. Meanwhile, I disabled rechecking and simply try until I get lucky during the NAT testing.
There is a hacky fix available: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...
participants (3)
-
0x5fcfbd30＠proton.me -
atari … -
Cecylia Bocovich