Standalone Snowflake NAT type problem

zerologs · December 8, 2024, 4:36pm

Hi All, I recently posted that I deployed a standalone snowflake proxy and it was running with NAT unrestricted for 4 days (ports 32678 to 60999) straight 100+ clients

BEFORE: STUN-NAT-Behaviour Test
NAT mapping behavior: endpoint independent ←
NAT filtering behavior: endpoint independent ←

and on the 5th day I noticed that I got fewer clients, so I just rebooted it and to my surprise the NAT became restricted and got almost fewer to no clients at all.

AFTER: STUN-NAT-Behaviour Test
NAT mapping behavior: endpoint independent ←
NAT filtering behavior: address and port dependent ←

My question is this normal or did my ISP took note of the large UDP traffic and decided to block it? Has anyone encountered this problem before? Thanks for the help.

tobrop · December 8, 2024, 4:42pm

Hello,

what comes to my mind:

Vort · December 8, 2024, 10:57pm

I noticed similar problem.
NAT detection produced wrong result right after start.
After proxy restart, type was detected correctly:

2024/12/03 21:03:01 Proxy starting
2024/12/03 21:03:21 NAT type: restricted
2024/12/03 21:04:06 Proxy starting
2024/12/03 21:04:08 NAT type: unrestricted

So it maybe enough to restart proxy several times.

BobbyB · December 8, 2024, 10:57pm

I don’t see why the ISP should/would care.

The only thing I can think of is when you reboot. Does the reboot automatically start the proxy like in a cronjob or do you start it manually all the time?

In that thread @tobrop links to I also said this:
I also found that on a machine reboot the proxy never started properly because I guess the machine was not really ready with the networking part.

I put a 3 minute delay in the cronjob for the reboot and that fixed it. Of course, as you know, I was not unrestricted yet and would not have noticed this.

I am unrestricted now, but I only have 9 clients.

Edited later:
So it just happened to me at 2024/12/08 21:57:11 UTC.
My public IP did not change, the router did not restart and neither did the proxy.
With only 9 clients I doubt it would raise awareness from my ISP.
This is the first time for me.
Next step is to restart the proxy.

Edited much later:
I’m quite tempted to make it 0 to disable it.

Once you start unrestricted, why would you want to retest. I assume the retest is there in the case where you are restricted for some reason when you should be unrestricted.
What could occur, other than a probe test which could make you go to restricted from unrestricted. For me it was the probe test.

Any thoughts about why the probe test is there for an unrestricted proxy startup.

meta4 · December 8, 2024, 10:57pm

You might try shorter NAT retest intervals using the -nat-retest-interval option. I’m currently using a value of 15m with good results.

zerologs · December 9, 2024, 10:21am

Hi All, thanks for all the replies I appreciate it. I found the problem which is quite odd but a user problem on my end not the snowflake proxy. I checked the port forwarding on the ISP/router and it checked out ok, ports are forwarded to the Google Wifi device.

The problem was on the Google wifi app where you port forward the ports to the snowflake proxy, the settings was gone and I don’t know why and I just re-entered the port values 32678 to 60999 saved it again.

I tested the ports using the Stun-NAT-Behaviour test and it worked and as of this writing I now have traffic on the snowflake proxy and is now back to unrestricted. I also adjusted the -capacity to 40, it used to be on the default which overwhelmed the RaspberryPi and crashed.

Network Flow: ISP modem/router → Google Wifi device → RaspberryPi Snowflake Proxy

github.com

pion/stun/blob/master/cmd/stun-nat-behaviour/README.md

# NAT behaviour discovery using STUN ([RFC 5780](https://tools.ietf.org/html/rfc5780))

This is an example of how to use the pion/stun package for client-side NAT
behaviour discovery. It performs two types of tests: one to determine the
client's NAT mapping behaviour, and one to determine the NAT filtering
behaviour.


### Usage
```sh
$ go install github.com/pion/stun/v3/cmd/stun-nat-behaviour@latest
$ $GOPATH/bin/stun-nat-behaviour [options] [--server IP:port]
```

If `$GOPATH` is unset it defaults to `~/go`

The default value `--server` is stun.voipgate.com:3478

Use `-h` to see all options

This file has been truncated. show original

Output from the Stun-NAT-Behaviour test.

INFO: 2024/12/08 23:47:16 Connecting to STUN server: stun.voipgate.com:3478
INFO: 2024/12/08 23:47:16 Local address: 0.0.0.0:47418
INFO: 2024/12/08 23:47:16 Remote address: 185.125.180.70:3478
INFO: 2024/12/08 23:47:16 Mapping Test I: Regular binding request
INFO: 2024/12/08 23:47:16 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2024/12/08 23:47:16 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2024/12/08 23:47:16 Received XOR-MAPPED-ADDRESS: x.x.x.x:47418
INFO: 2024/12/08 23:47:16 Mapping Test II: Send binding request to the other address but primary port
INFO: 2024/12/08 23:47:16 Sending to 185.125.180.71:3478: (20 bytes)
INFO: 2024/12/08 23:47:16 Response from 185.125.180.71:3478: (100 bytes)
INFO: 2024/12/08 23:47:16 Received XOR-MAPPED-ADDRESS: x.x.x.x:47418
WARNING: 2024/12/08 23:47:16 => NAT mapping behavior: endpoint independent ←
INFO: 2024/12/08 23:47:16 Connecting to STUN server: stun.voipgate.com:3478
INFO: 2024/12/08 23:47:16 Local address: 0.0.0.0:33377
INFO: 2024/12/08 23:47:16 Remote address: 185.125.180.70:3478
INFO: 2024/12/08 23:47:16 Filtering Test I: Regular binding request
INFO: 2024/12/08 23:47:16 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2024/12/08 23:47:16 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2024/12/08 23:47:16 Filtering Test II: Request to change both IP and port
INFO: 2024/12/08 23:47:16 Sending to 185.125.180.70:3478: (28 bytes)
INFO: 2024/12/08 23:47:17 Response from 185.125.180.71:3479: (100 bytes)
WARNING: 2024/12/08 23:47:17 => NAT filtering behavior: endpoint independent ←

This is what I’m looking for both NAT mapping and filtering are endpoint independent.
WARNING: 2024/12/08 23:47:16 => NAT mapping behavior: endpoint independent ←
WARNING: 2024/12/08 23:47:17 => NAT filtering behavior: endpoint independent ←

Finally I can put this problem to rest and let the Snowflake Proxy run for as long as it takes.

zerologs · December 9, 2024, 10:21am

Thanks will try that…

zerologs · December 9, 2024, 10:21am

Thanks you are correct about the ISP not caring. I’m just a small blip on the radar.

zerologs · December 9, 2024, 10:21am

Thanks for the link

WofWca · December 9, 2024, 10:21am

So, you are using the NAT testing tool stun/cmd/stun-nat-behaviour at master · pion/stun · GitHub. It’s good in helping isolate the problem from the proxy’s code, so potential probetest server issues are ruled out! So it’s not this issue.

Indeed, the AFTER measurement result is a “restricted” NAT type for a proxy.

Do you mind checking again whether the NAT test tool used a port inside the range that you specified (“ports 32678 to 60999”)?

For better understanding, Snowflake proxy doesn’t use the same method as the NAT test tool (linked above). Snowflake proxy instead tries to establish a connection with a centralized server with a deliberately set up restricted NAT. If the connection succeeds, the proxy considers itself unrestricted.

zerologs · December 9, 2024, 11:05am

Yes thanks for replying back, I posted new info above… and I checked the output of the NAT test tool on the Raspberry Pi hosting the Snowflake Proxy and indeed it was using the port range values that I specified .

system · December 10, 2024, 10:28pm

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.