stunserver.stunprotocol.org supports NAT behavior test over udp/tcp, but can't find any other equivalent replacement on the internet. I guess it's a needle in a haystack.
If possible, hope to provide a list of servers that support RFC5780. Thank you.

Hey :)

as up-to-date STUN servers lists are often needed to be known in-browser, and you might not want to hard-code them, you can actually use this code in-browser to fetch them fresh from GitHub, and Microsoft will pay for the traffic + takes care for DDoS protection:

const stunServerList = (await (await fetch(
      'https://raw.githubusercontent.com/pradt2/always-online-stun/master/valid_ipv4s.txt'
)).text()).split('\n')

The README contains a section about being able to remove stun servers from parties that don't want their servers listed here - but is there a tracking mechanism to prevent them from being added by someone else in the future again?

Should there be a file similar to candidates.txt that lists out servers that have specifically asked to not be a part of this project? Or is there some other, better, way that you can track which servers should be rejected from new issues/PRs?

Only a few servers support tcp protocol, for example, stun.mixvoip.com:3478. Hope to add a list of whether the server supports stun over tcp protocol. Thank you.

I love the STUN list, but if you could also have a list of servers that allow anonymous TURN that would be A+.

Anyway, thanks for the list!

Hi,

Thanks for this list, this is going to be super useful for my little project to find out what port ranges are used for cgnat!

I noticed that I don't get any response for lots of hosts in the hourly updated valid_ipv4s.txt using my own script pystun, I tried to validate this by running "run.sh" on Fedora 35 but that's even worse (all hosts seem to fail):

OK 0 , DNS failure 78 , p/Timeout 0 , Timeout 508 , Incorrect 47

I guess there could be a difference in connectivity depending on the Internet connection, it would also be very helpful if the capabilities of the stun servers are available.

Our current geolocation provider requires an API key and limits the number of requests. Let's switch to one that does not do that, such as geolocation-db.com

Hey there,

we would like to get stun.sipgate.net permanently removed from the list.

Thanks,
Daniel

My udp/tcp/v4/v6 stun server: stun.flashdance.cx:3478

Combine with https://www.npmjs.com/package/freeice to automatically have random valid STUN servers without extra config.

Hey,

another one, I've wrote a TypeScript script to allocate geo location data per IP.
This can be extremely helpful for selecting the nearest and fastest STUN server.
Results attached as JSON.

import { Lookup, lookup } from "geoip-lite"
import { readFileSync, writeFileSync } from "fs"

interface ServerWithGeoLocation {
    ip: string
    port: number
    geoLocation: Lookup | null
}
const stunServersWithGeo: Array<ServerWithGeoLocation> = []

JSON.parse(readFileSync('stunServerIps.json', {
    encoding: 'utf8'
})).map((stunServer: string) => {

    const serverAddress = stunServer.split(':')
    const ip = serverAddress[0]
    const port = parseInt(serverAddress[1], 10)

    stunServersWithGeo.push({
        ip,
        port,
        geoLocation: lookup(ip)
    })
})

writeFileSync(
  'stunServersWithGeoLocation.json', 
  JSON.stringify(stunServersWithGeo, null, 2), 
  { encoding: 'utf8' }
)

The file: stunServerIps.json contains the STUN server addresses like this:

[
    "37.97.65.52:3478",
    "158.69.57.20:3478",
    "150.254.161.60:3478",
    "44.224.155.217:3478",
    "176.9.24.184:3478",
     ...
 ]

In general I can only recommend saving them as JSON too because it's easier accessible in many programming languages.

Result looks like this:

[{
   "ip": "203.13.68.16",
   "port": 3478,
   "geoLocation": {
     "range": [
       3406644224,
       3406645247
     ],
     "country": "AU",
     "region": "QLD",
     "eu": "0",
     "timezone": "Australia/Brisbane",
     "city": "Varsity Lakes",
     "ll": [
       -28.0867,
       153.4116
     ],
     "metro": 0,
     "area": 1
   }
 }, ... ]

This can be easily matches client-side with the result from a GeoLocation API call at client-side in-browser:

import * as tzlookup from "tz-lookup"

const getGeoLocation = () => {

 navigator.geolocation.getCurrentPosition((position) => {
   console.log('position', position)

   const timeZone = tzlookup(position.coords.latitude, position.coords.longitude)
   console.log('timeZone', timeZone)
 }, () => {
   console.error('Error fetching GeoLocation')
 });
}

And thus timeZone will report:

...and we can simply go thru the nearest STUN servers now and connect to these.

stunServersWithGeoLocation.json.zip

Hi there.

stun.kedr.io:3478 is currently responding with faulty information: It advertises an OTHER-ADDRESS attribute containing the same IP address that was used to contact it. (The port is different, but that's not enough to avoid breaking things.)

This tricks clients that understand and use that attribute into thinking their NAT's filtering behavior is the most permissive possible (Endpoint-Independent Filtering) even if it actually is much more restrictive.

It also violates RFC 5780, which states, "OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the server has a second IP address."

Given that this is likely to undermine NAT traversal, I think it might be worth removing that server from the list for now, and maybe contacting the admins to see if they'll fix it.

(To be clear in light of the FAQ, the problem here isn't a lack of RFC 5780 support; that would be harmless.)

Hey :)

this project is truly amazing! The only thing I think that could make it even better is a self-triggering GitHub action.
It seems like that the Rust scripts being triggered "externally". But this would "stop" if the "central" infra that triggers this update script stops working for some reason. But if implemented as a GitHub Action, this would run forever, and be much more resilient?

Self-triggering can be approached when you build a GitHub Action that registers an action on push that runs the rust, and then waits a while (NOP) before it pushes to the very same repo -> recursion.

Thanks a lot for your work here!