FEDAnet project

previous • index

Check your NAT!

Fri Jun 13 23:30:00 2025 UTC

No beautifully-looking timestamp was any close to today's date, so let's celebrate Friday 13 :-)

You're welcome to the download page, where the feda-ng-0.0.03.tgz tarball is available. As usual, it contains everything needed to compile the node key generator (that feda-ng program), the challenge table manipulation program (feda-ct) and the cryptographic key&cert manipulation program (fedakeys); but the main novelty today is the program named natcheck, which lets the user to determine what type of NAT (if any) is in effect at the present internet connectivity. Run it as natcheck -v -v.

The check requires a system of servers (at least two of them), collaborating with each other. The servers I currently run are named nc1.feda.croco.net, nc2.feda.croco.net and nc3.feda.croco.net. By default, the first one is used as the main, and the other two play the sibling role. However, if the main server is for any reason not available, please try any of the other two, with a command like natcheck -v -v nc2.feda.croco.net.

Please expect all kinds of malfunction, the code is not mature enough now. And, well, NO, I'm not going to publish the server's source code right now: in its present state such a publishing would be a kind of exhibitionism. Definitely I'll make the server code available when the time comes; please be patient.

And one more thing guys: please share your results in comments here.

P.S.: For those who don't remember: the HTML tag you need to enclose listings and terminal output logs is <pre> :-)

comment on this

From Maxim N. (unverified) Thu Jun 19 16:28:50 2025 UTC

NAT Check

Hi. Results of my NAT check on one of the devices I have:

user01@Mac feda-ng-0.0.03 % ./natcheck -v -v             
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:54253
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 94.230.230.126:54253
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 94.230.230.126:54253
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 94.230.230.126:54253
got 2 replies, all peers see us at the same address
----------------------
Looks like RESTRICTED CONE type of NAT; not too bad.
Check the file NAT_TYPES for explanation
user01@Mac feda-ng-0.0.03 %

Context: location Uzbekistan, home Wi-Fi network, device MacOS laptop. Maybe later I'll run check on other devices too if it will be helpful for you.

From Andrey Stolyarov Thu Jun 19 18:29:35 2025 UTC in reply to this comment

Re: NAT Check

So it works on Mac? Expectable, but nonetheless very sad :-(

From Maxim N. (unverified) Thu Jun 19 21:22:09 2025 UTC in reply to this comment

Re: Re: NAT Check

Yes, it worked but I was needed it to compile not statically; just running make gived errors for some reason (changed make file).

Why sad though? Isn't it good?

From Andrey Stolyarov Thu Jun 19 21:41:16 2025 UTC in reply to this comment

Re: Re: Re: NAT Check

It's not only bad, it's horrible. I'm going to do my best to keep Apple's devices of any kind (specially iPhones, but all other stuff as well) off this network. Well, natcheck is a simple program, I hope programs that deal with tunnels and traffic forwarding won't work on MacOS. It is possbile I'll need to make heavy use of something Linux-specific to prevent any kind of compatibility with MacOS, despite that it will ruin compatibility with FreeBSD and other BSDs as well.

Unfortunately, it is senseless to just check and refuse to work, as in an open source program there's no problem for anyone to simply remove the check.

From Maxim N. (unverified) Thu Jun 19 21:55:08 2025 UTC in reply to this comment

Re: Re: Re: Re: NAT Check

Anyway, here is result of running NAT check on my Arch Linux machine:

(130)(deck@steamdeck feda-ng-0.0.03)$ ./natcheck -v -v
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:53396
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 94.230.230.126:53396
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 94.230.230.126:53396
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 94.230.230.126:53396
got 2 replies, all peers see us at the same address
----------------------
Looks like RESTRICTED CONE type of NAT; not too bad.
Check the file NAT_TYPES for explanation
(deck@steamdeck feda-ng-0.0.03)$

Same context: Uzbekistan, home Wi-Fi network. PS: this time compiled fine statically with just make. (Assuming something strange was with Mac).

From Andrey Stolyarov Thu Jun 19 22:02:45 2025 UTC in reply to this comment

Re: Re: Re: Re: Re: NAT Check

Well, the NAT type doesn't depend on the machine which sits behind the NAT and/or its O.S. type :)

From Maxim N. (unverified) Fri Jun 20 00:47:16 2025 UTC in reply to this comment

Re: NAT Check

Sorry I don't know exactly how much records you need for your statistics so here is one more check run I've made:

user01@Mac feda-ng-0.0.03 % ./natcheck -v -v
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:54667
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 188.113.236.62:8492
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 188.113.236.62:8506
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 188.113.236.62:8506
got 2 replies, they see us as DIFFERENT addresses; too bad
----------------------
Looks like SYMMETRIC NAT type of NAT; too bad.
Check the file NAT_TYPES for explanation
user01@Mac feda-ng-0.0.03 %

Context: Location Uzbekistan, Mac laptop, Network is Wi-Fi from Android phone shared hot-spot, Android uses mobile cellular network.

From Yury (unverified) Mon Jun 16 10:09:18 2025 UTC

natcheck result

This is what I've got:

root@home-nl:~/feda-ng-0.0.03# ./natcheck -v -v -b 5000
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
localport value is set to 5000
my local socket address: 0.0.0.0:5000
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 62.194.153.78:5000
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 62.194.153.78:5000
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 62.194.153.78:5000
got 2 replies, all peers see us at the same address
----------------------
Looks like RESTRICTED CONE type of NAT; not too bad.
Check the file NAT_TYPES for explanation

Netherlands, cable connection through the provider's router (it connects to the provider using coax, so I can't connect directly to my PC). Fortunately, port forwarding works: if I run nc -l 5000 and then connect from my VPS to the PC using port 5000, it works fine. It's a bit strange that it reports "RESTRICTED CONE."

From Andrey Stolyarov Mon Jun 16 11:04:33 2025 UTC in reply to this comment

Re: natcheck result

Why, that's not strange. When you send a datagram to one of the nc?.feda.croco.net servers, everything goes well, but after that, the other two servers send you datagrams on the same addr/port, and those are rejected by your NAT (until you send something to them using the same socket). As of port forwarding, didn't you explicitly set it for the TCP port 5000, or for a port range, or anything else like that?

Anyway, if you have a VPS, perhaps (once all the stuff is ready) the simplest solution will be just to run fedaproxy there.

From Yury (unverified) Mon Jun 16 11:04:33 2025 UTC in reply to this comment

Re: natcheck result

Ohh, I'm sorry, I forgot to close pre tag. :-( Also, I apparently misconfigured port forwarding, it has to be UDP, while I configured it for TCP... After I fixed the forwarding rule it's now:

Looks like FULL CONE type of NAT (or even no NAT at all). Excellent!

From Andrey Stolyarov Mon Jun 16 11:31:23 2025 UTC in reply to this comment

Re: Re: natcheck result

Not that you forgot to close it, you rather tried to open it again :-) No problem, I fixed that. As of ports, well, I expected smth. like that. For UDP there are no simple programs like nc or telnet, so people (yes, even network engineers and programmers) tend to forget about its very existence. Actually, unexpected renaissance of UDP happend only because various audio-video conferencing over IP became popular, and for UDP all this port-punching is at least possible.

From Yury (unverified) Mon Jun 16 16:46:23 2025 UTC in reply to this comment

Re: Re: Re: natcheck result

What is your take on Tcp vs Udp for general purpose?

From Andrey Stolyarov Mon Jun 16 19:13:54 2025 UTC in reply to this comment

Re: natcheck result

Well, definitely it is always possible to create a more efficient protocol for a particular task with UDP rather than with TCP; the problem is that only small amount of fantastically overqualified people (eh... wizards? cyborgs?) are able to really gain something this way, and the development time and costs will raise several times (if not orders of magnitude). So, in most cases, as far as there are no really serious reasons, I'd do everything with TCP. And I always did.

With FEDAnet, such really serious reasons obviously exist. And, believe it or not, this is the first project in my life where UDP is envolved.

Well, I know exactly one case when UDP obviously gives gain and costs virtually nothing, it is connectivity between VPN endpoints. You don't need any reliability for these IP packets wrapped up by your own protocol, just because the actual communicating parties handle lost packets on their own. IP as such assumes no responsibility for actual delivery, and loosing some of VPN datagrams will add nothing serious to is. At the other hand, when you tunnel TCP over TCP (which obviously happen when any TCP connection works over a TCP-based tunnel), you do have some totally useless overhead: two reliability controlling levels instead of just one.

From Yury (unverified) Tue Jun 17 12:37:11 2025 UTC in reply to this comment

Re: Re: natcheck result

Just wanted to note that I (topic starter) am a different Yury than the one who asked about UDP vs. TCP...

From Maxim Klochkov (unverified) Sun Jun 15 14:27:20 2025 UTC

natcheck results

Hi, I've made two tests, first one on my home linux box, and second one on the virtual machine located in data center in Europe.

First result:

mk@***:~/src/feda/feda-ng-0.0.03$ ./natcheck -v -v nc1.feda.croco.net
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:34080
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 95.143.218.56:34080
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 95.143.218.56:34080
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 95.143.218.56:34080
got 2 replies, they see us as DIFFERENT addresses; too bad
----------------------
Looks like SYMMETRIC NAT type of NAT; too bad.
Check the file NAT_TYPES for explanation

Second result:

mk@***:~/src/feda-ng-0.0.03$ ./natcheck -v -v nc1.feda.croco.net
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:51440
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 46.149.73.238:51440
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 46.149.73.238:51440
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 46.149.73.238:51440
got 2 replies, all peers see us at the same address
----------------------
Looks like RESTRICTED CONE type of NAT; not too bad.
Check the file NAT_TYPES for explanation

From blackcat49 (unverified) Sat Jun 14 13:07:03 2025 UTC

natcheck result

~/b/feda-ng-0.0.03 ❯❯❯ ./natcheck -v -v
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:52393
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 193.194.97.170:52393
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 193.194.97.170:52393
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 193.194.97.170:52393
got 2 replies, all peers see us at the same address
----------------------
Looks like RESTRICTED CONE type of NAT; not too bad.
Check the file NAT_TYPES for explanation

From Anon (unverified) Sat Jun 14 07:36:26 2025 UTC

Formatting result

Could you explain which formatting is convenient for you? When I send output as is it looks ugly so I delimit lines by extra empty lines. Should I use certain html tag?

From Andrey Stolyarov Sat Jun 14 12:19:41 2025 UTC in reply to this comment

Re: Formatting result

Sure. Please enclose your citation within <pre> and </pre>. Thank you!

From Anon (unverified) Sat Jun 14 07:30:51 2025 UTC

natcheck result

normal messages enabled

info messages enabled

debug messages enabled

will contact 172.245.129.210:65242

my local socket address: 0.0.0.0:45783

received 128 bytes from 172.245.129.210:65242

got 128 bytes from 172.245.129.210:65242 (cmd 7f)

they see us as 223.24.146.20:4292

suggested to expect: sibling server 188.44.43.17:65242

suggested to expect: sibling server 45.13.38.102:65242

total: 2 sibling servers

received 128 bytes from 45.13.38.102:65242

got 128 bytes from 45.13.38.102:65242 (cmd 57)

received 128 bytes from 188.44.43.17:65242

got 128 bytes from 188.44.43.17:65242 (cmd 57)

timed out

got the server's reply and 2 dgrams from others

----------------------

Looks like FULL CONE type of NAT (or even no NAT at all). Excellent! Check the file NAT_TYPES for explanation

From Andrey Stolyarov Sat Jun 14 08:43:03 2025 UTC in reply to this comment

Re: natcheck result

WOW, grats! Could you please tell where you are, geografically?

From Anon (unverified) Sat Jun 14 09:09:37 2025 UTC in reply to this comment

Re: Re: natcheck result

Thailand on mobile internet

From Andrey Stolyarov Sat Jun 14 12:16:57 2025 UTC in reply to this comment

Re: natcheck result

Thank you! You're the first to report full cone on a mobile connection; I started to get nervous as if Android itself performs NAT of a restricted type.

From feriman (unverified) Sat Jun 14 07:25:57 2025 UTC

natcheck log

~/src/feda-ng-0.0.03 $ ./natcheck -v -v nc1.feda.croco.net
normal messages enabled
info messages enabled
debug messages enabled
will contact 172.245.129.210:65242
my local socket address: 0.0.0.0:41996
received 128 bytes from 172.245.129.210:65242
got 128 bytes from 172.245.129.210:65242 (cmd 7f)
they see us as 46.97.169.236:60704
suggested to expect: sibling server 188.44.43.17:65242
suggested to expect: sibling server 45.13.38.102:65242
total: 2 sibling servers
timed out
got the server's reply but no others, second stage is needed
sending feda echo req. to 188.44.43.17:65242
sending feda echo req. to 45.13.38.102:65242
received 160 bytes from 45.13.38.102:65242
got 160 bytes from 45.13.38.102:65242
they see us as 46.97.169.236:52382
received 160 bytes from 188.44.43.17:65242
got 160 bytes from 188.44.43.17:65242
they see us as 46.97.169.236:45344
got 2 replies, they see us as DIFFERENT addresses; too bad
----------------------
Looks like SYMMETRIC NAT type of NAT; too bad.
Check the file NAT_TYPES for explanation

From Andrey Stolyarov Sat Jun 14 12:21:26 2025 UTC in reply to this comment

Re: natcheck log

Bastard operators from hell (BOFHs) definitely aren't going to die out.

From feriman (unverified) Sat Jun 14 16:11:40 2025 UTC in reply to this comment

Re: Re: natcheck log

Vodafone, RO.

From Andrey Stolyarov Sat Jun 14 17:30:27 2025 UTC in reply to this comment

Re: natcheck log

Phone operators are generally not very good at providing IP connectivity. But, well, symmetric is shame — if only it's not your equipment causing this (which is unlikely but possible).

From feriman (unverified) Sat Jun 14 17:47:27 2025 UTC in reply to this comment

Re: Re: natcheck log

I'm using a phone as a router.

From Andrey Stolyarov Sat Jun 14 19:04:01 2025 UTC in reply to this comment

Re: Re: Re: natcheck log

I've got somewhat strong impression that things depend heavily on the settings and on the phone (well, mostly the OS, be in Android or iOS) version. I can't check it. What I know for sure that long long time ago (like, maybe, seven years ago) I had the FullCone through a smartphone, but a lot of things could get changed since then.

From feriman (unverified) Sat Jun 14 21:00:43 2025 UTC in reply to this comment

Re: Re: Re: Re: natcheck log

Of course, I just give the information as requested, trying to participate as possible as I can for the moment. Thank you for your books, projects, and for yourself.

From Andrey Stolyarov Sat Jun 14 21:07:37 2025 UTC in reply to this comment

Well, thank you

It is a commonplace
And we all know
That flattery is base,
And mean, and low.
However, all in vain,
And flatterers were, are, and will remain.

One day a Crow
Found luckily a decent piece
Of cheese,
After a long and forced fast.
To a big oak she flies fast
To have a breakfast
There in peace,
And almost has begun,
But was distracted by some thought
(I do not know, about what).
Unfortunately, a sly Fox has run
Not far. The cheese she smelt
And also sort of hungry felt.
Then to the oak-tree she did tiptoe,
Looking with admiration at the Crow,
And said in her most sugar voice,
"Sweetheart, I very much rejoice
In meeting such a beauty in our land.
Oh, what a neck, beak, feathers, and
An elegant smart wing!
I bet, just like an angel you should sing.
Well, darling, don't be shy,
Just try!
If in addition to looks that nice
You also have a pleasant voice,
The whole forest will rejoice
And you'll be valued thrice."

The speech like that
Completely reeled the head
Of the poor Crow,
And she did caw,
With all air in her craw.
Fell out the piece
Of cheese.
And our story ends at this.

Sorry, couldn't resist :-)

From Ray Traycing (unverified) Sun Jun 15 18:46:16 2025 UTC in reply to this comment

typo fix

sed -i '179s/sohaving/so having/' NAT_TYPES

From Andrey Stolyarov Mon Jun 16 11:45:30 2025 UTC in reply to this comment

Re: typo fix

Thanks. I fixed the source, so this typo will disappear in the next release.