# Snowflake proxy NAT type changes to restricted on retest
**URL:** https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969
**Category:** Support
**Tags:** snowflake
**Created:** [November 24, 2024, 10:08am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969 "2024-11-24T10:08:35Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@tobrop](https://forum.torproject.org/u/tobrop)
#### Post date: [November 24, 2024, 10:08am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/1 "2024-11-24T10:08:35Z")
As it happened the 2nd time… during the start of the Snowflake proxy - I’m on commit [c5d68034](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/c5d680342b33c24ffe6a4a5e85d70376de4660e0) - it correctly shows “NAT unrestricted”.
After 24hrs ( `nat-retest-interval`), for whatever reasons, the NAT type changes to restricted.
```auto
2024/11/24 09:23:05 Checking our NAT type, contacting NAT check probe server at "https://snowflake-broker.torproject.net:8443/probe"...
2024/11/24 09:23:05 Probetest: Created Offer
2024/11/24 09:23:05 Probetest: Set local description
2024/11/24 09:23:05 Probetest offer:
...
2024/11/24 09:23:10 Waiting for a test WebRTC connection with NAT check probe server to establish...
2024/11/24 09:23:10 NAT check: WebRTC: OnConnectionStateChange: connecting
2024/11/24 09:23:30 Test WebRTC connection with NAT check probe server timed out. This means our NAT is restricted.
2024/11/24 09:23:30 NAT Type measurement: unrestricted -> restricted
2024/11/24 09:23:30 NAT check: WebRTC: OnConnectionStateChange: closed
```
followed by many `bad offer from broker`.
Does anyone have an idea?
---
### Author:  [@BobbyB](https://forum.torproject.org/u/BobbyB)
#### Post date: [November 25, 2024, 12:11am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/2 "2024-11-25T00:11:22Z")
Did you see this post on my thread?
> [@Planning for my proxy as Unrestricted](https://forum.torproject.org/t/planning-for-my-proxy-as-unrestricted/15909/8):
>
> If the modem reboots i suggest restarting the snowflake process because the state will go again to unknown=restricted. At least this happens to my machines. If modem gets a new ip the users count drops to 5-10 from 80-120.
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 cron job for the reboot and that fixed it. Of course, as you know, I was not unrestricted yet and would not have noticed this.
---
### Author:  [@tobrop](https://forum.torproject.org/u/tobrop)
#### Post date: [November 25, 2024, 12:11am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/3 "2024-11-25T00:11:32Z")
After I checked my router log, the reason could be the nightly change of the IP by the router.
Nevertheless, the question remains as to why the proxy behaves in this way - 6 hours after the router has requested a new IP.
---
### Author:  [@WofWca](https://forum.torproject.org/u/WofWca)
#### Post date: [November 25, 2024, 12:11am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/4 "2024-11-25T00:11:34Z")
Does this happen often? Does it go back to “unrestricted” after another 24 hours?
Here is a related post: [Planning for my proxy as Unrestricted - #8 by SirNeo](https://forum.torproject.org/t/planning-for-my-proxy-as-unrestricted/15909/8)
@SirNeo Is the “restricted” state sustained over time or does it eventually go back to “unrestricted” if you wait for another 24 hours?
---
### Author:  [@tobrop](https://forum.torproject.org/u/tobrop)
#### Post date: [November 25, 2024, 8:19am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/5 "2024-11-25T08:19:19Z")
> [@WofWca](#):
>
> Does it go back to “unrestricted” after another 24 hours?
What I can say for the moment, if the proxy is in this restricted state and I restart the proxy (Docker container) the NAT type is unrestricted again.
---
### Author:  [@BobbyB](https://forum.torproject.org/u/BobbyB)
#### Post date: [November 25, 2024, 8:19am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/6 "2024-11-25T08:19:23Z")
I can see the logic of why it has this behaviour. Anything which is connected (clients or those 2 STUN servers) now cannot because the IP is different. Any left over rules in the router for connection tracking is mixed up and it falls to restricted. Same as if it the router rebooted. There is nothing to tell the proxy to retest the NAT type. It’s the best I can explain it.
I assume it only does that NAT testing when you start the proxy. Maybe it should also do it when it’s public IP changes.
I see this option in the startup command:
-nat-retest-interval duration
the time interval in second before NAT type is retested, 0s disables retest. Valid time units are “s”, “m”, “h”. (default 24h0m0s)
---
### Author:  [@WofWca](https://forum.torproject.org/u/WofWca)
#### Post date: [November 25, 2024, 10:59am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/7 "2024-11-25T10:59:53Z")
> [@BobbyB](#):
>
> Anything which is connected (clients or those 2 STUN servers) now cannot because the IP is different.
Are you talking about Snowflake clients? I don’t think this could explain it because failed client connections do not affect the NAT type value in standalone Snowflake.
> [@BobbyB](#):
>
> There is nothing to tell the proxy to retest the NAT type.
But, as the author says, the test gets performed, and it shows “restricted”.
> [@BobbyB](#):
>
> I assume it only does that NAT testing when you start the proxy
Yes, by default it re-tests the NAT type every 24 hours.
For debugging it could help to reduce this interval.
---
### Author:  [@BobbyB](https://forum.torproject.org/u/BobbyB)
#### Post date: [November 25, 2024, 5:22pm UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/8 "2024-11-25T17:22:37Z")
> [@WofWca](#):
>
> Are you talking about Snowflake clients? I don’t think this could explain it because failed client connections do not affect the NAT type value in standalone Snowflake.
No, I meant that the router gets mixed up. The probe test does occur and the author states a nightly IP change. It’s unclear. Does it occur every night? Did the router re-boot? Did the probe test occur in that sweet spot between when the IP is changing and the network stabilized with the new IP.
Maybe unrestricted to restrict should trigger a wait for some time and do it again. I doubt unrestricted to restrict should be a natural thing.
---
### Author:  [@tobrop](https://forum.torproject.org/u/tobrop)
#### Post date: [November 26, 2024, 4:45pm UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/9 "2024-11-26T16:45:30Z")
A test with _-nat-retest-interval 4m_
After start of proxy: unrestricted
> **Summary**
>
> 2024/11/26 16:24:34 Probetest offer:
> v=0
> o=- 2962057035657345861 1732638274 IN IP4 [scrubbed]
> s=-
> t=0 0
> a=msid-semantic:WMS\*
> a=fingerprint:sha-256 F0:13:C5:DD:E8:02:7F:87:CD:2F:50:1F:47:B3:51:32:6A:E1:96:6A:BC:B4:44:C5:06:C4:94:16:6C:13:CE:45
> a=extmap-allow-mixed
> a=group:BUNDLE 0
> m=application 9 UDP/DTLS/SCTP webrtc-datachannel
> c=IN IP4 [scrubbed]
> a=setup:actpass
> a=mid:0
> a=sendrecv
> a=sctp-port:5000
> a=ice-ufrag:hfPEPAJzZzlAKxlS
> a=ice-pwd:namKJQwoAMOCjcaJSuxjoVzjNswoXFoF
> a=candidate:2516015194 1 udp 2130706431 [scrubbed] 52410 typ host
> a=candidate:2516015194 2 udp 2130706431 [scrubbed] 52410 typ host
> a=candidate:1777299242 1 udp 1694498815 [scrubbed] 52408 typ srflx raddr [scrubbed] rport 52408
> a=candidate:1777299242 2 udp 1694498815 [scrubbed] 52408 typ srflx raddr [scrubbed] rport 52408
> a=candidate:1777299242 1 udp 1694498815 [scrubbed] 52401 typ srflx raddr [scrubbed] rport 52401
> a=candidate:1777299242 2 udp 1694498815 [scrubbed] 52401 typ srflx raddr [scrubbed] rport 52401
> a=end-of-candidates
4 minutes later: restricted. The offer has no candidates?!
> **Summary**
>
> 2024/11/26 16:28:36 Probetest offer:
> v=0
> o=- 4030829343340168843 1732638516 IN IP4 [scrubbed]
> s=-
> t=0 0
> a=msid-semantic:WMS\*
> a=fingerprint:sha-256 9F:5A:4D:F8:40:FA:71:B3:8A:B1:A1:79:C0:84:4E:69:59:39:07:8F:6A:4B:9F:9A:92:BA:00:6D:32:4F:5C:A8
> a=extmap-allow-mixed
> a=group:BUNDLE 0
> m=application 9 UDP/DTLS/SCTP webrtc-datachannel
> c=IN IP4 [scrubbed]
> a=setup:actpass
> a=mid:0
> a=sendrecv
> a=sctp-port:5000
> a=ice-ufrag:fSmHKdMENxfBSKfq
> a=ice-pwd:pRQPLRlMWNmYgVFzkuyKeKQVINMGDlSJ
> a=end-of-candidates
4 minutes later: unrestricted
> **Summary**
>
> 2024/11/26 16:33:01 Probetest offer:
> v=0
> o=- 8458135077210308682 1732638776 IN IP4 [scrubbed]
> s=-
> t=0 0
> a=msid-semantic:WMS\*
> a=fingerprint:sha-256 FA:6A:36:7B:8B:15:16:BC:45:7E:B7:C0:9C:DA:9C:97:DE:91:54:41:D7:CA:9F:58:38:67:DD:D3:F6:F5:D0:2A
> a=extmap-allow-mixed
> a=group:BUNDLE 0
> m=application 9 UDP/DTLS/SCTP webrtc-datachannel
> c=IN IP4 [scrubbed]
> a=setup:actpass
> a=mid:0
> a=sendrecv
> a=sctp-port:5000
> a=ice-ufrag:pvwFKMDQarkJEOWB
> a=ice-pwd:grLkgGtYlzTTAjYPSQzRzVbUrSCmQQgV
> a=candidate:2516015194 1 udp 2130706431 [scrubbed] 52413 typ host
> a=candidate:2516015194 2 udp 2130706431 [scrubbed] 52413 typ host
> a=candidate:1777299242 1 udp 1694498815 [scrubbed] 52414 typ srflx raddr [scrubbed] rport 52414
> a=candidate:1777299242 2 udp 1694498815 [scrubbed] 52414 typ srflx raddr [scrubbed] rport 52414
> a=end-of-candidates
4 minutes later: unrestricted
> **Summary**
>
> 2024/11/26 16:37:02 Probetest offer:
> v=0
> o=- 9057977459703951 1732639022 IN IP4 [scrubbed]
> s=-
> t=0 0
> a=msid-semantic:WMS\*
> a=fingerprint:sha-256 F3:5B:92:56:3B:E8:A2:5E:9C:E9:77:C9:A6:EE:1D:BF:36:DC:FB:C1:9F:06:65:1A:AD:3C:1A:E0:B6:61:E9:CD
> a=extmap-allow-mixed
> a=group:BUNDLE 0
> m=application 9 UDP/DTLS/SCTP webrtc-datachannel
> c=IN IP4 [scrubbed]
> a=setup:actpass
> a=mid:0
> a=sendrecv
> a=sctp-port:5000
> a=ice-ufrag:qRzBMLHCCnpFRkYg
> a=ice-pwd:LUJXoYpoVmdhIfatHOUsyrJqokcMEiwf
> a=candidate:2516015194 1 udp 2130706431 [scrubbed] 52404 typ host
> a=candidate:2516015194 2 udp 2130706431 [scrubbed] 52404 typ host
> a=candidate:1777299242 1 udp 1694498815 [scrubbed] 52414 typ srflx raddr [scrubbed] rport 52414
> a=candidate:1777299242 2 udp 1694498815 [scrubbed] 52414 typ srflx raddr [scrubbed] rport 52414
> a=candidate:1777299242 1 udp 1694498815 [scrubbed] 52407 typ srflx raddr [scrubbed] rport 52407
> a=candidate:1777299242 2 udp 1694498815 [scrubbed] 52407 typ srflx raddr [scrubbed] rport 52407
> a=end-of-candidates
---
### Author:  [@BobbyB](https://forum.torproject.org/u/BobbyB)
#### Post date: [November 26, 2024, 8:12pm UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/10 "2024-11-26T20:12:22Z")
Not exactly sure what these are saying.
I wondered if losing internet connectivity could do it.
I did my own experiment since I knew when my re test was due. I disconnected the cable. All clients dropped. Waited about 3 minutes then reconnected. It kept on going as if nothing happened. At the proper time I saw the probe test occur but did not see a _NAT Type measurement:_
Not exactly sure what this is saying either.
In tomorrow’s test I will reconnect the cable after the probe test occurs.
---
### Author:  [@tobrop](https://forum.torproject.org/u/tobrop)
#### Post date: [November 26, 2024, 8:34pm UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/11 "2024-11-26T20:34:39Z")
For me, the above behavior shows that a test can lead to a timeout and thus to _restricted_ despite an established Internet connection.
My temporary solution is that if the test fails, it is repeated one time after 2 seconds.
---
### Author:  [@BobbyB](https://forum.torproject.org/u/BobbyB)
#### Post date: [November 27, 2024, 3:42am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/12 "2024-11-27T03:42:25Z")
Agreed with that. Above I wrote:
_“Maybe unrestricted to restrict should trigger a wait for some time and do it again. I doubt unrestricted to restrict should be a natural thing.”_
If your mod works, it should be a default action.
---
### Author:  [@WofWca](https://forum.torproject.org/u/WofWca)
#### Post date: [November 27, 2024, 11:09am UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/13 "2024-11-27T11:09:07Z")
> [@tobrop](#):
>
> The offer has no candidates?!
Isn’t this the `-ephemeral-ports-range` shenanigans again? [Remote returned status code 400 - #21 by tobrop](https://forum.torproject.org/t/remote-returned-status-code-400/15026/21)
---
### Author:  [@tobrop](https://forum.torproject.org/u/tobrop)
#### Post date: [November 27, 2024, 12:52pm UTC](https://forum.torproject.org/t/snowflake-proxy-nat-type-changes-to-restricted-on-retest/15969/14 "2024-11-27T12:52:24Z")
No, the matter with the ports is resolved.
Thought this might be the or a reason why the retest fails.