Snowflake proxy NAT type changes to restricted on retest

As it happened the 2nd time… during the start of the Snowflake proxy - I’m on commit c5d68034 - it correctly shows “NAT unrestricted”.

After 24hrs ( nat-retest-interval), for whatever reasons, the NAT type changes to restricted.

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?

Did you see this post on my thread?

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.

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.

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
@SirNeo Is the “restricted” state sustained over time or does it eventually go back to “unrestricted” if you wait for 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.

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)

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.

But, as the author says, the test gets performed, and it shows “restricted”.

Yes, by default it re-tests the NAT type every 24 hours.

For debugging it could help to reduce this interval.

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.

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

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.

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.

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.

Isn’t this the -ephemeral-ports-range shenanigans again? Remote returned status code 400 - #21 by tobrop

No, the matter with the ports is resolved.

Thought this might be the or a reason why the retest fails.