Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-11-07T00:11:57Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40305Upgrade tor on snowflake bridges to 0.4.8.8 for TROVE 2023 0042023-11-07T00:11:57ZDavid Fifielddcf@torproject.orgUpgrade tor on snowflake bridges to 0.4.8.8 for TROVE 2023 004https://lists.torproject.org/pipermail/tor-relays/2023-November/021373.html
> Today (2023-11-03) the Network Team has released [new Tor versions 0.4.7.16 and 0.4.8.8](https://forum.torproject.org/t/security-release-0-4-7-16-and-0-4-8-8/...https://lists.torproject.org/pipermail/tor-relays/2023-November/021373.html
> Today (2023-11-03) the Network Team has released [new Tor versions 0.4.7.16 and 0.4.8.8](https://forum.torproject.org/t/security-release-0-4-7-16-and-0-4-8-8/10064). These updates contains a fix to a remote crash bug (TROVE 2023 004). It is highly recommended that all relay operators upgrade to the new versions as soon as possible to maintain the network stability and security.
>
> For those running their Tor relay using the Tor Debian repository, expect the new deb package to be available soon.
>
> The patches prevents the issue from causing a crash in Tor. However, it will make Tor more noisy when the bug is triggered, including logging information about the remote peer that is the source or destination of the circuit in the path. Such information is important for our developers to diagnose the specific invariant within Tor's TLS logic that does not hold.
- [x] snowflake-01
- [x] snowflake-02
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2023-11-06https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40304Update the list of RFC 5780 compatible STUN servers2024-02-27T11:04:02ZCecylia BocovichUpdate the list of RFC 5780 compatible STUN serversWhen looking at some client logs, I noticed several of the following messages:
```
WARNING: 2023/11/02 18:40:42 Error: NAT discovery feature not supported by this server
```
It appears that several of our default STUN servers at the cli...When looking at some client logs, I noticed several of the following messages:
```
WARNING: 2023/11/02 18:40:42 Error: NAT discovery feature not supported by this server
```
It appears that several of our default STUN servers at the client no longer support this feature. This may partially explain the high number of unknown client NAT types that we see in the metrics.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40303Show number of currently open connections in hourly standalone proxy log output2023-12-13T19:18:04ZCecylia BocovichShow number of currently open connections in hourly standalone proxy log outputFrom @arma in #40302:
> as an operator I want to hear about how many connections are open right now. This number might be quite a bit higher than our current stats imply, if some small fraction of connections stay open for many epochs. O...From @arma in #40302:
> as an operator I want to hear about how many connections are open right now. This number might be quite a bit higher than our current stats imply, if some small fraction of connections stay open for many epochs. Or it might not be, I'm not sure.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40302Proxy hourly stats did not actually happen during that hour2023-10-30T16:44:18ZRoger DingledineProxy hourly stats did not actually happen during that hourMy snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relaye...My snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relayed ↓ 561833 KB, ↑ 97282 KB.
2023/10/27 11:53:58 In the last 1h0m0s, there were 63 connections. Traffic Relayed ↓ 124717270 KB, ↑ 6237157 KB.
2023/10/27 12:53:58 In the last 1h0m0s, there were 48 connections. Traffic Relayed ↓ 745608 KB, ↑ 97699 KB.
```
That "125 gigabytes" entry translates to... almost 35 megabytes per second of traffic, on average during the hour? Probably by only a few or even one user? This did not happen during that hour.
Looking at proxy/lib/pt_event_logger.go:
```
case event.EventOnProxyConnectionOver:
e := e.(event.EventOnProxyConnectionOver)
p.inboundSum += e.InboundTraffic
p.outboundSum += e.OutboundTraffic
p.connectionCount += 1
```
I.e. what is happening here is that the stats for the entire connection are counted during the hour that it closed.
See the forum for somebody else reporting this same issue (forum post noticed courtesy MarkC on irc): https://forum.torproject.org/t/impossible-metric-for-snowflake-proxy/9941/1
We should either (a) make the hourly "In the last 1h0m0s," be accurate, in the sense that they actually tell me what happened in the last 1h0m0s, or (b) change the log message so it's clearer it is telling me how many connections finished during that hour along with total transfer on those recently-closed connections.
I'd prefer solution 'a', since it is what I thought I was getting out of these log entries, and I was using it to e.g. try to judge what timezones my snowflake is popular.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40301Non-fronted connections to the broker no longer work since 9fdfb3d1b53e911342...2023-10-30T16:27:44ZCecylia BocovichNon-fronted connections to the broker no longer work since 9fdfb3d1b53e9113422a7a2816b2a9af4450b4acThe changes in !182 caused a regression for client configurations that only provide a `url=` option and not a `front=` option. The check at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/4fa43a889...The changes in !182 caused a regression for client configurations that only provide a `url=` option and not a `front=` option. The check at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/4fa43a88927e42fb2e3864f706d3e3c72fd0dca3/client/lib/rendezvous_http.go#L49 is never false, causing a connection to a blank URL to happen if no front is provided:
```
2023/10/26 14:46:44 Negotiating via HTTP rendezvous...
2023/10/26 14:46:44 Target URL: snowflake-broker.torproject.net
2023/10/26 14:46:44 Front URL:
2023/10/26 14:46:44 WebRTC: closing DataChannel
2023/10/26 14:46:44 WebRTC: closing PeerConnection
2023/10/26 14:46:44 WebRTC: Closing
2023/10/26 14:46:44 WebRTC: dial tcp :443: connect: connection refused Retrying...
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40300snowflake client is lazy for exact 24 hours2024-02-27T13:22:50Ztoralfsnowflake client is lazy for exact 24 hoursHappened for 2 clients within last few days with latest git-HEAD : The client is up and running and has network connections to _snowflake-01_, but it is doing nothing - and is working in a normal way without any intervention after 1 day....Happened for 2 clients within last few days with latest git-HEAD : The client is up and running and has network connections to _snowflake-01_, but it is doing nothing - and is working in a normal way without any intervention after 1 day. Here're the Grafana metrics:
![image](/uploads/5c2ce560adc435eda8433179e3410f02/image.png)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40299snowflake-01: Change upper value for local port range2024-01-24T02:15:41ZLinus Nordberglinus@torproject.orgsnowflake-01: Change upper value for local port rangeWe have increased the range of local TCP and UDP ports to span from 15000 and 64000 inclusive.
The kernel has opinions and prints the following at boot:
> kernel: ip_local_port_range: prefer different parity for start/end values.
https...We have increased the range of local TCP and UDP ports to span from 15000 and 64000 inclusive.
The kernel has opinions and prints the following at boot:
> kernel: ip_local_port_range: prefer different parity for start/end values.
https://docs.kernel.org/5.10/networking/ip-sysctl.html explains that
> If possible, it is better these numbers have different parity (one even and one odd value).
I suggest we change the upper value to 63999 for upcoming boots by editing /etc/sysctl.d/ip_local_port_range.conf.
/cc @dcfLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40298snowflake-01: Upgrade Debian 11 -> 122024-02-17T22:21:09ZLinus Nordberglinus@torproject.orgsnowflake-01: Upgrade Debian 11 -> 12I'd like to upgrade snowflake-01 to bookworm (12).
Which packages are crucial to have tested before, and have they been tested elsewhere?\
Is snowflake-02 running Debian?
/cc @dcfI'd like to upgrade snowflake-01 to bookworm (12).
Which packages are crucial to have tested before, and have they been tested elsewhere?\
Is snowflake-02 running Debian?
/cc @dcfLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.org2024-02-18https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40297snowflake-01: Upgrade to Debian 11.82023-10-20T18:53:37ZLinus Nordberglinus@torproject.orgsnowflake-01: Upgrade to Debian 11.8I'd like to upgrade snowflake-01 from Debian 11.7 to 11.8.
This will bring, among other things, a new kernel, new grub and tor (`0.4.8.6-1~d11.bullseye+1` to `0.4.8.7-1~d11.bullseye+1`).
Is this something that needs coordination or ca...I'd like to upgrade snowflake-01 from Debian 11.7 to 11.8.
This will bring, among other things, a new kernel, new grub and tor (`0.4.8.6-1~d11.bullseye+1` to `0.4.8.7-1~d11.bullseye+1`).
Is this something that needs coordination or can I do it any time?Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40296Snowflake Broker Deployment 23-10-162023-10-19T17:12:53ZshelikhooSnowflake Broker Deployment 23-10-16This deployment is needed to end ip churn collection(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40280).
Code to be deployed: v2.7.0
## Deployment Script
```
sv stop snowflake-broker
cp /et...This deployment is needed to end ip churn collection(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40280).
Code to be deployed: v2.7.0
## Deployment Script
```
sv stop snowflake-broker
cp /etc/service/snowflake-broker/run ./snowflake-broker-run-23-10-16-backup-$(date +%N)
cp /usr/local/bin/broker ./snowflake-broker-23-10-16-backup-$(date +%N)
install --owner root ./snowflake-broker-run-23-10-16-candidcate /etc/service/snowflake-broker/run
install --owner root ./snowflake-broker-23-10-16-candidcate /usr/local/bin/broker
sv start snowflake-broker
```
## New Run File
```
#!/bin/sh -e
setcap 'cap_net_bind_service=+ep' /usr/local/bin/broker
exec chpst -u snowflake-broker -o 32768 /usr/local/bin/broker --metrics-log /home/snowflake-broker/metrics.log --acme-hostnames snowflake-broker.bamsoftware.com,snowflake-broker.freehaven.net,snowflake-broker.torproject.net --acme-email dcf@torproject.org --acme-cert-cache /home/snowflake-broker/acme-cert-cache --bridge-list-path /home/snowflake-broker/bridge_lists.json --default-relay-pattern ^snowflake.torproject.net$ --allowed-relay-pattern snowflake.torproject.net$ 2>&1
```
### Binary To Be Deployed
```
1be8764d1a9328bd0f36706fbc040557da102134c78463d0d5470d97cac90903 broker
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40295Restart broker without proxy churn measurements2023-11-02T16:43:25ZDavid Fifielddcf@torproject.orgRestart broker without proxy churn measurementsNow that the proxy churn code has been removed (#40280),
we need to restart the broker with the new code.
Then we can can call the current log file complete and ready it for publication.
The file /etc/runit/snowflake-broker/run needs to...Now that the proxy churn code has been removed (#40280),
we need to restart the broker with the new code.
Then we can can call the current log file complete and ready it for publication.
The file /etc/runit/snowflake-broker/run needs to be edited to remove `-ip-count-*` options.
The key in `-ip-count-mask` needs to be destroyed.
One difficulty here is that the /etc directory on the broker
is version-controlled using [etckeeper](https://etckeeper.branchable.com/) (Git).
It is necessary to remove the key not only from the file /etc/runit/snowflake-broker/run
but also from the version history.
That may require rewriting history with `git rebase -i`,
followed by `git gc`.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40294Client README recommends command-line options rather than bridge line arguments2024-01-05T22:28:35ZDavid Fifielddcf@torproject.orgClient README recommends command-line options rather than bridge line argumentssnowflake-client, for backward compatibility reasons,
accepts some configuration options as command line options (e.g. `-front`, `-ice`)
as an alternative to the (preferred) format of setting those options
in a bridge line (e.g. `front=`...snowflake-client, for backward compatibility reasons,
accepts some configuration options as command line options (e.g. `-front`, `-ice`)
as an alternative to the (preferred) format of setting those options
in a bridge line (e.g. `front=`, `ice=`).
The command-line versions are needed only for very very old versions of tor.
The bridge line args are preferred because the scope of command-line options is global,
while bridge line args are specific to a single tor SOCKS connection
(so you can have multiple bridge lines with different options).
The client README still documents and recommends the old command-line options:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/d434549df88292ff6e61830dc06a49b0ac1b21c6/client/README.md#running-the-snowflake-client-with-tor
> The Snowflake client can be configured with either command line options or SOCKS options. We have a few example `torrc` files in this directory. We recommend the following `torrc` options by default:
>
> ```
> UseBridges 1
>
> ClientTransportPlugin snowflake exec ./client \
> -url https://snowflake-broker.torproject.net.global.prod.fastly.net/ \
> -front cdn.sstatic.net \
> -ice stun:stun.voip.blackberry.com:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
>
> Bridge snowflake 192.0.2.3:1
> ```
We should update these to recommend bridge line args instead,
as is already the case [in torrc](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/d434549df88292ff6e61830dc06a49b0ac1b21c6/client/torrc).
The command-line options don't even need to be documented IMO.
Here's a case of a user on NTC being confused by the README:
https://ntc.party/t/in-case-snowflake-rendezvous-gets-blocked/1857/28.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40293snowflake-01: OOB unreachable2023-10-04T08:10:19ZLinus Nordberglinus@torproject.orgsnowflake-01: OOB unreachableThe OOB system for snowflake-01 was unreachable yesterday when we wanted to reboot in #40292.The OOB system for snowflake-01 was unreachable yesterday when we wanted to reboot in #40292.Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40292snowflake-01: Reboot needed2023-10-12T16:25:26ZLinus Nordberglinus@torproject.orgsnowflake-01: Reboot neededI'd like to reboot snowflake-01 in order to restart every every thing.
I'm going to coordinate this with the data center people since our OOB system is sad.
LMK if there's a better or worse time for a reboot.
/cc @dcfI'd like to reboot snowflake-01 in order to restart every every thing.
I'm going to coordinate this with the data center people since our OOB system is sad.
LMK if there's a better or worse time for a reboot.
/cc @dcfLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40291container image on Docker Hub behind current release2024-02-14T16:39:15ZHarmonics6527container image on Docker Hub behind current release"latest"-Tag on Docker hub (https://hub.docker.com/r/thetorproject/snowflake-proxy/tags) is at 2.6.0
Current release here is 2.6.1 - is some kind of automation broken?"latest"-Tag on Docker hub (https://hub.docker.com/r/thetorproject/snowflake-proxy/tags) is at 2.6.0
Current release here is 2.6.1 - is some kind of automation broken?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40290standalone snowflake README still says go 1.15+ needed2023-10-20T15:25:32ZRoger Dingledinestandalone snowflake README still says go 1.15+ neededThe proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two t...The proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two things:
* We should update the README to reflect current requirements
and
* We should figure out what we want to tell people on Debian, who can no longer build snowflake, if they don't want to engage in installing and maintaining the whole toolchain manually. Do they stick with v2.6.1? Do they turn off their snowflake? Something even smarter? ...and then write that in the README too.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40289prometheus metrics: inbound traffic is a magnitude higher than outbound ?2023-10-20T15:24:55Ztoralfprometheus metrics: inbound traffic is a magnitude higher than outbound ?Me wonders about these numbers :
```
~/devel/tor-relays $ hcloud server list --output columns=name | grep -v NAME | sort | while read i; do echo; echo $i; ssh -n $i 'curl -s localhost:9999/internal/metrics | grep "^tor.*traffic"'; done
...Me wonders about these numbers :
```
~/devel/tor-relays $ hcloud server list --output columns=name | grep -v NAME | sort | while read i; do echo; echo $i; ssh -n $i 'curl -s localhost:9999/internal/metrics | grep "^tor.*traffic"'; done
buddelflink
tor_snowflake_proxy_traffic_inbound_bytes_total 1.5137087637e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.842859221e+09
drehrumbum
tor_snowflake_proxy_traffic_inbound_bytes_total 2.616226932e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.428826961e+09
elster2
tor_snowflake_proxy_traffic_inbound_bytes_total 2.4824487988e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.756696966e+09
hoppel2
tor_snowflake_proxy_traffic_inbound_bytes_total 1.8561349297e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.831598894e+09
igel
tor_snowflake_proxy_traffic_inbound_bytes_total 2.203970161e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.038998589e+09
moppi3
tor_snowflake_proxy_traffic_inbound_bytes_total 2.1562580774e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.572686488e+09
nickeneck
tor_snowflake_proxy_traffic_inbound_bytes_total 1.7488402935e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.840865957e+09
pittiplatsch
tor_snowflake_proxy_traffic_inbound_bytes_total 2.0007601682e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 1.980735179e+09
putzi
tor_snowflake_proxy_traffic_inbound_bytes_total 2.2191193167e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.005800589e+09
schwarzrock
tor_snowflake_proxy_traffic_inbound_bytes_total 2.2477079962e+10
tor_snowflake_proxy_traffic_outbound_bytes_total 2.340506538e+09
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40288Use shadow for integration testing in gitlab CI2024-02-27T18:50:58ZCecylia BocovichUse shadow for integration testing in gitlab CIShadow provides an easy way to perform simple integration testing.
Arti already uses shadow for integration testing: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/.gitlab-ci.yml?ref_type=heads#L264-L374Shadow provides an easy way to perform simple integration testing.
Arti already uses shadow for integration testing: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/.gitlab-ci.yml?ref_type=heads#L264-L374https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40287warning: snowflake-proxy.service: Failed at step USER spawning /usr/bin/proxy...2023-09-23T19:59:45Ztoralfwarning: snowflake-proxy.service: Failed at step USER spawning /usr/bin/proxy: No space left on device"Realized this message today at several of my proxies while deploying latest git version [1] :
```
"Aug 28 16:17:47 buddelflink systemd[1]: Stopping snowflake-proxy.service - snowflake-proxy...",
"Aug 28 16:17:47 buddelfl...Realized this message today at several of my proxies while deploying latest git version [1] :
```
"Aug 28 16:17:47 buddelflink systemd[1]: Stopping snowflake-proxy.service - snowflake-proxy...",
"Aug 28 16:17:47 buddelflink systemd[1]: snowflake-proxy.service: Deactivated successfully.",
"Aug 28 16:17:47 buddelflink systemd[1]: Stopped snowflake-proxy.service - snowflake-proxy.",
"Aug 28 16:17:47 buddelflink systemd[1]: snowflake-proxy.service: Consumed 9h 58min 268ms CPU time.",
"Aug 28 16:17:47 buddelflink systemd[1]: Started snowflake-proxy.service - snowflake-proxy.",
"Aug 28 16:17:47 buddelflink (proxy)[296443]: snowflake-proxy.service: Failed to set up user namespacing: No space left on device",
"Aug 28 16:17:47 buddelflink (proxy)[296443]: snowflake-proxy.service: Failed at step USER spawning /usr/bin/proxy: No space left on device",
"Aug 28 16:17:47 buddelflink systemd[1]: snowflake-proxy.service: Main process exited, code=exited, status=217/USER",
"Aug 28 16:17:47 buddelflink systemd[1]: snowflake-proxy.service: Failed with result 'exit-code'.",
"Aug 28 16:17:52 buddelflink systemd[1]: snowflake-proxy.service: Scheduled restart job, restart counter is at 1.",
"Aug 28 16:17:52 buddelflink systemd[1]: Stopped snowflake-proxy.service - snowflake-proxy.",
"Aug 28 16:17:52 buddelflink systemd[1]: Started snowflake-proxy.service - snowflake-proxy.",
"Aug 28 16:17:52 buddelflink (proxy)[296453]: snowflake-proxy.service: Failed to set up user namespacing: No space left on device",
"Aug 28 16:17:52 buddelflink (proxy)[296453]: snowflake-proxy.service: Failed at step USER spawning /usr/bin/proxy: No space left on device",
"Aug 28 16:17:52 buddelflink systemd[1]: snowflake-proxy.service: Main process exited, code=exited, status=217/USER",
"Aug 28 16:17:52 buddelflink systemd[1]: snowflake-proxy.service: Failed with result 'exit-code'.",
"Aug 28 16:17:57 buddelflink systemd[1]: snowflake-proxy.service: Scheduled restart job, restart counter is at 2.",
"Aug 28 16:17:57 buddelflink systemd[1]: Stopped snowflake-proxy.service - snowflake-proxy.",
"Aug 28 16:17:57 buddelflink systemd[1]: Started snowflake-proxy.service - snowflake-proxy.",
"Aug 28 16:17:57 buddelflink proxy[296457]: 2023/08/28 16:17:57 Proxy starting",
"Aug 28 16:18:05 buddelflink proxy[296457]: 2023/08/28 16:18:05 NAT type: unrestricted"
```
Seemed to heal itself but IMO worth to be reported.
Installed version is latest git HEAD (v2.5.1-46-ga3bfc28).
[1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-snowflake/tasks/snowflake.yamlhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40286On IPv6-only server, always "NAT type: unknown" even with firewall disabled2023-10-21T16:18:43Zcatharsis71On IPv6-only server, always "NAT type: unknown" even with firewall disabledI have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames w...I have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames with AAAA records resolve normally and go out directly
there is no access to raw IPv4 IP addresses
running snowflake-proxy, I always get "NAT type: unknown" even if my firewall is completely disabled... is this intended behavior?
I've tested both the Docker container and compiling/running locally but the results are the same
the proxy does seem to work but normally only gets 0-3 connections per hour per proxy (seemingly unaffected by whether the firewall is up or down)
perhaps this is due to the small pool of IPV6 clients wanting to connect, but I'm not sure
snowflake.torproject.net has an AAAA record so traffic to it does not go through NAT64
likewise stun.l.google.com has an AAAA record so traffic to it does not go through NAT64
I am unable to determine the cause of the "NAT type: unknown"