FEDAnet project

Proposal Readings Download License Donate

previous • index • next

Let's play tunnels

Mon Sep 8 23:10:00 2025 UTC

A new version of the source code tarball (0.0.30) has just been published. The good news is that this version is actually capable of running IPv6 tunnels over the IPv4 Internet. Unfortunately, the bad news is that almost nothing of the proposed key features are implemented. In this miserable version, the fedaserv instances can not find each other, can not exchange broadcast announces, can not act as a rendes-vous assistant for others, there's no database of known nodes' locations... well, there's almost nothing. Despite the IPv6 connectivity is somehow possible, I admit it is not very useful without all the infrastructure; folks, let's put it this way: I needed to convince myself I'm able to deal with IPv6 packets and their forwarding.

Long things short, a node in this version must run on a public ip:port pair, and all connections are to be configured manually. The best thing one can achieve is the two-ways connectivity between points of different nodes, provided that the nodes have an active cryptographic association between them (again, configured manually). For details, please see the file POORMANSVPN inside the tarball.

So, if you have a VPS or smth. like that to run a node, let's play tunnels. I decided not to interfere with my own NAT checking servers; my node, c508097bd6c347a4a317, is running at ip 45.13.38.102, port 5080. The nodecert file for it is here: c508097bd6c347a4a317.pub. If you want to try peering with me (and possibly other fanatics as well), please publish your addr/port and the nodecert file somewhere, and post a link here in the comments. If you can't publish the information anywhere, just copy-paste the nodecert file to the comment and add the IP/port information. I'm going to accept all certs with rank 20 and higher, and may be I'll even maintain a collection of the known certs as a single archive.

Guys, here's a little challenge. I run a single-page webserver on the address feda:c508:097b:d6c3:47a4:a317:3700:feda, port 80, as usual. Take a screenshot of it :-)

Thanks to everyone who supported the project.

comment on this

From Parthen Wed Sep 17 20:42:52 2025 UTC

It's working!

I managed to visit OP's and Yury's websites. Really cool to see that its loading with average speed. I'm too traumatized with Tor and I2P speeds :/

I also managed to setup some silly website. I added everyone here as my peers, so feel free to try it :)

(Fully compatible with text browsers btw)

From Parthen Wed Sep 17 09:14:31 2025 UTC

Peer review

peer parthen
type natcheck
ip 64.188.75.96
port 65242

http://parthen.site/fedanet/290467092770dbde244e.pub

I want to setup some site in this, is there any newbie guide?

From Andrey Stolyarov Wed Sep 17 09:46:14 2025 UTC in reply to this comment

Re: Peer review

Node cert checked (rank 24).

BTW, I downloaded it successfully from my home computer, but when I tried to do the same wget from my VPS, it redirected me to some crap of, presumably, your hosting company (timeweb). That crap says (in Russian) the domain is parked. So far, I only see that from within my VPS, and from my home the file is opened correctly.

Next, in the logs I see this:

Sep 17 09:27:38 [1011178] association with 64.188.75.96:65242 (290467092770dbde244e.0) established (!)

It is actually a bug that fedaserv agrees to run with point number zero, it definitely shouldn't. The fedaserv instance running on behalf of its node must have the point number 254 (0xFE). ZeroPoint is used to sign keys for other points on behalf of the node, instead of the master key (and this is the only thing ZeroPoint is for), and hence it shouldn't be deployed on machines exposed to attacks, such as servers.

I'd recommend you to regenerate your ZeroPoint using the master key (because the existing ZeroPoint was exposed to your hosting company's personnel, as they actually have full access to VPS containers' content), then generate point 254 using ZeroPoint. At your server, deploy point254 instead of the old ZeroPoint (be sure to rm -r .fedanet/keys/*.* before that).

I want to setup some site in this, is there any newbie guide?

You run some web sites on IPv4 addresses, don't you? Running sites on IPv6 addresses shouldn't be very different, except that we don't have domain names in FEDAnet so far, so all virtualization is to be done basing on the IP addresses... errr... but you have a lot of them, don't you? :) E.g. on the machine where your node runs, you can configure any amount of addresses of the form FEDA:(node-id):PPxx:xxxx, where PP is 00, FE or FF, and xx:xxxx are any hex digits. If you decide to bring up a point other than 0xFE, e.g., on your home machine, the situation is generally the same, only the PP must correspond to the point number.

From Parthen Wed Sep 17 10:08:05 2025 UTC in reply to this comment

Re: Re: Peer review

>timeweb

Yeah, I'm in process of domain transfer right now. Could you say where your VPS is located? Output of wget also would be useful.

>zeropoint

Ohh, my bad. Somehow I missread zeropoint as zeronode, lol

>but you have a lot of them, don't you

Not really, actually. The only "real" server is parthen.site. Second one, home.parthen.site is just a subdomain for my home PC, in case I urgently need some files on it.

From Andrey Stolyarov Wed Sep 17 12:08:28 2025 UTC in reply to this comment

Re: Re: Re: Peer review

> where your VPS is

According to RIPE Db, it is in Bucharest, but I'm not sure this info is accurate.

> Output of wget also would be useful.

Take it at http://www.croco.net/xx/out.txt

> Not really, actually.

Errr... I mean, you have a lot of FEDAnet IPv6 addresses. And yes you do! Each point has 16777216 (2^24) of them, and the node actually can use 3*16777216 (with "point numbers" 0, 254 and 255, a.k.a. 0x00, 0xFE, 0xFF) for its own purposes. So, in effect, you can configure as many IPv6 addresses on your feda0 interface as you want, and your HTTP server will tell sites one from another by their configured IPv6 addresses, this is called "IP-based virtual hosting".

From Parthen Wed Sep 17 12:18:37 2025 UTC in reply to this comment

Re: Peer review

Point fixed, connnection established (hi Ilya and Yury!). I also setup home peer (feda:2904:6709:2770:dbde:244e:100:feda), but I can't ping anyone (even my own nodes) both from node and home peer.

Does anyone able to ping me?

From Andrey Stolyarov Wed Sep 17 14:13:11 2025 UTC in reply to this comment

Re: Re: Peer review

From my point (the same machine where my test site is):

PING feda:2904:6709:2770:dbde:244e:feda:feda(feda:2904:6709:2770:dbde:244e:feda:feda) 56 data bytes
64 bytes from feda:2904:6709:2770:dbde:244e:feda:feda: icmp_seq=1 ttl=61 time=46.8 ms
64 bytes from feda:2904:6709:2770:dbde:244e:feda:feda: icmp_seq=2 ttl=61 time=45.8 ms

Your home address isn't pingable now. With a proper configuration, you definitely must be able to ping your node from your home machine (well, you see, if it is pingable from my home machine, err...), so keep checking configuration and all the things around until it pings :-)

From Parthen Wed Sep 17 20:34:45 2025 UTC in reply to this comment

Re: Re: Re: Peer review

Yeah, I simply didn't specify feda0 in config. Now everything seems working.

From feriman Tue Sep 16 09:54:06 2025 UTC

Peer

peer vetal
type natcheck
ip 107.174.224.199
port 65242

http://drago.loongie.net/files/f226cb6a4412d7faa2c1.pub

From Andrey Stolyarov Tue Sep 16 10:14:05 2025 UTC in reply to this comment

Re: Peer

Checked (rank 20), looks working. Any internal address to ping?

From feriman Tue Sep 16 10:23:00 2025 UTC in reply to this comment

Re: Re: Peer

I just have running the fedaserv. I'm not sure what to do with it at the moment... By the way, natcheck from my workstation ocassionally start to work with fedaserv on my vps (it was timed out) but I did not change anything...

From Andrey Stolyarov Tue Sep 16 13:09:48 2025 UTC in reply to this comment

Re: Re: Re: Peer

Well, you can bring up the tun network interface (typically feda0) either at your node's machine, or at a machine where a connected point runs, or even on both. Take a look at the POORMANSVPN file within the source tarball, there's a detailed step-by-step instruction.

From feriman Tue Sep 16 17:25:03 2025 UTC in reply to this comment

Re: Re: Re: Re: Peer

Yes, I already have the feda0 interface up and running accordingly to POORMANSVPN guide as you mentioned above. Also I have 0, 1, 254, and node files in the corresponding subdirectory of ~/.fedanet/keys/ on my vps. I see the output of fedaserv about established associations (including my vps' ip address); but I'm unable to `curl' your site from my vps. Seems I need some help.

From Andrey Stolyarov Tue Sep 16 17:45:55 2025 UTC in reply to this comment

Re: Re: Re: Re: Re: Peer

> Also I have 0, 1, 254, and node files in the corresponding subdirectory of ~/.fedanet/keys/ on my vps.

This sounds very strange. A VPS is supposedly a server where the node is to run, and the node is represented by the 'magic' point 254 (0xFE). To my mind, there's absolutely no reason of having ZeroPoint, nor point 1, nor any other point on the VPS, only the point 254. ZeroPoint should rather be deployed on your workstation, where it is convenient for you to sign certificates for other points. Point #1 (or actually any in the range 1..253) can also be deployed on the workstation to connect your workstation to FEDAnet through your node.

Furthermore, any single point can be deployed along with ZeroPoint side-by-side, but you can't have more points at the same location. So actually I don't understand what do you mean when you say "I have 0, 1, 254".

If you bring up the feda0 interface on your VPS (where the node runs), it should perhaps be configured with the IPv6 address FEDA:(node-id):FEDA:FEDA. Well, in your particular case it will be feda:f226:cb6a:4412:d7fa:a2c1:feda:feda. Also the block feda::0/16 (the whole FEDAnet) should be routed to that interface. It is shown in the POORMANSVPS file how to set this up.

If you decide to bring up a point (#1?) at your home computer (workstation), there you should perhaps use the IPv6 address feda:f226:cb6a:4412:d7fa:a2c1:0100:feda (note that "01" in the 12th byte, it must be the local point number). Again, there must be the route for feda::0/16 to the interface.

Last thing to mention, be sure to check if you have lines like

forwarding yes
tun_iface feda0

in your serv.conf on each of the machines where either a packet forwarding or the feda0 interface are to be supported (in this case, perhaps on both machines).

UPD: In my node's logs, I see this:

Sep 16 15:13:18 [755400] association with 107.174.224.199:65242 (f226cb6a4412d7f
aa2c1.254) established (remote req.)

So, at least the point number at your node's location is configured properly (254). Now you should check the serv.conf, the IPv6 address at the interface (BTW, is it pingable from inside the VPS? it definitely should), and the route. Once we have the node address accessible, it will perhaps be the time to bring up a point at your home computer.

From feriman Tue Sep 16 20:40:57 2025 UTC in reply to this comment

Re: Re: Re: Re: Re: Re: Peer

It works now. The screenshot of your site: http://drago.loongie.net/files/20250916_232816.png

Thank you for help!

From Andrey Stolyarov Tue Sep 16 20:49:00 2025 UTC in reply to this comment

Re: Peer

May be you give the rest of us an address to ping? :-) I'm glad you were able to access the site, but having no address we can't do anything on our own to see if your node is still there.

From feriman Wed Sep 17 07:40:18 2025 UTC in reply to this comment

Re: Re: Peer

Yes, sure :-) I was so sleepy last night. I have enabled ICMPv6 in iptables, so the node address is able to ping. feda:f226:cb6a:4412:d7fa:a2c1:feda:feda

From Andrey Stolyarov Wed Sep 17 09:14:01 2025 UTC in reply to this comment

Re: Re: Re: Peer

Yeah, it's reachable. Great.

From Ilya Wed Sep 10 10:14:45 2025 UTC

Peer

peer ilya
type natcheck
ip 132.145.107.156
port 65242

wget -O 102028623c1cef4a81c1.pub https://files.catbox.moe/ek3hj2.pub

From Andrey Stolyarov Wed Sep 10 13:24:29 2025 UTC in reply to this comment

Re: Peer

Checked (rank 25), looks working. Any address to ping? :-)

From Ilya Wed Sep 10 13:35:37 2025 UTC in reply to this comment

Re: Re: Peer

The unknown node errors stopped, however, running curl [feda:c508:097b:d6c3:47a4:a317:3700:feda]:80 hungs indefinitely, here are repeating -vvv logs

[7838a861] sending with seq. 1 cmdbyte D0
sending encrypted dgram (cmd=d0, size=109/84) to 45.13.38.102:5080
sent 109 bytes to 45.13.38.102:5080 [cbcd92931d...]; 0 unsent for the peer

From Andrey Stolyarov Wed Sep 10 14:34:20 2025 UTC in reply to this comment

Re: Re: Re: Peer

I noticed you use the point number 1. There are no special assumptions about this point number, it's just a point. So my node knows how to reach your point-1's subnet (that is, FEDA:(node-id):01xx:xxxx), as it has direct connection to it, but it doesn't know how to reach any other addresses within your node subnet, outsize of that 01xx:xxxx. It is very possible this is the problem.

The fedaserv instance running on behalf of its node must have the point number ~~256~~ 254 (0xFE; sorry, "256" was a typo). If a directly connected peer has this point number, it is assumed to be the valid next hop for the whole node's /96 block.

The good news here is that no corrections are needed from my side: my node already knows your cert, so it will happily accept connections from any of your points.

From Ilya Wed Sep 10 14:47:02 2025 UTC in reply to this comment

Re: Re: Re: Re: Peer

So what should be done on my side? Should I create a new point? I tried actually, I ran "fedakeys -p zcrpoint 44" and then "fedakeys -p deploy [key file]", and it gave me error "FATAL: .fedanet/keys/feda.conf already exists, move/delete it and retry", thats why I worked with what I had and used FEDA:(node-id):FEDA:FEDA as an address, as described in the docs. Should I move feda.conf somewhere, run the command again, and move it back?

From Andrey Stolyarov Wed Sep 10 15:23:48 2025 UTC in reply to this comment

Re: Peer

Just remove .fedanet/keys/feda.conf AND .fedanet/keys/secret.key, you don't need them, fedakeys deploy will create you new files :-) Then, at the location where you have your ZeroPoint, do fedakeys zcrpoint 254, copy the _p254.key to the location of your node, and perform fedakeys -p deploy whatever_p254.key (-p suppresses the hash check, it might be useful if the node is to be run on a low-class machine).

From Ilya Wed Sep 10 16:19:43 2025 UTC in reply to this comment

Re: Re: Peer

I'm sorry, I don't get it. Now that I deleted those files, zcrpoint complains

 kfiles: .fedanet/keys/feda.conf: No such file or directory. Couldn't get the point configuration

> fedakeys deploy will create you new files

this command takes filename as an argument, which one is it? the only "secret" files I have are zeropoint.key (and master key on a separate machine), I deleted the rest.

From Andrey Stolyarov Wed Sep 10 16:36:10 2025 UTC in reply to this comment

Re: Re: Re: Peer

Ah, okay. I didn't expect you having ZeroPoint in the same location as the node, this is generally not desirable. ZeroPoint is used only to create/sign other points' keys, so it should reside on your workstation, not on the server, and the node typically works on a server.

Together with the ZeroPoint, you can deploy any other point in the same location, but this is supposed to be your personal point (number 1? actually, any in the range 1..253, it's up to you). Well, likely you can deploy the "magic" point 254 together with the ZeroPoint, but, well, it looks strange for me to use the server machine to create/sign ordinary points' keys.

Now that you deleted your ZeroPoint deployment (sorry for this, again, I just didn't expect such a setup) you should first re-deploy the ZeroPoint (errr... remove that .fedanet/keys/zeropoint.key file first, or it will fail). If you already erased your nodeID_p0.key file, use your master key to make a new one. If you really want so, you can do this all at the same location as your node is supposed to run, despite I strongly recommend to think again before you do. Even deploying the ZeroPoint at the same location with your master keys looks more natural to me.

Once you deployed ZeroPoint, use it to create the key for point 254, and use the nodeID_p254.key to deploy the point at the location where the node is to be run.

From Ilya Wed Sep 10 18:26:35 2025 UTC in reply to this comment

Re: Re: Re: Re: Peer

Okay, now I finally got it working and was able to load your website

So those are the steps I've done:

1) deploy master from master key, then generate zeropoint key
2) copy zeropoint key from isolated machine to my main workstation and continue from there
3) on the workstation, deploy zeropoint from zeropoint key, then generate keys for other points (like 254)
4) copy keys for other points to my server, and continue from there
5) on the server, deploy the points, import certs, etc

P.S. I was actually able to access the website from my main workstation, by running

ssh user@server-address -f -N -D 7777

and then adding 127.0.0.1:7777 to the browser proxy settings. Actually, any software can be proxyfied this way using mgraftcp or proxychains, which makes me even question the need to write software for point end-users, since you won't be writing for Windows or Android.

From Andrey Stolyarov Wed Sep 10 20:07:59 2025 UTC in reply to this comment

Re: Re: Re: Re: Re: Peer

> 5) on the server, deploy the points, import certs, etc

This step sounds strange for me. Only the node (a.k.a. point 254) is supposed to run on the server. If you have other servers, it might be desirable to run fedaserv instances on them to build a nat-checking system, but I actually don't see any other valid purposes for other points to run on server machines.

To connect your workstation to FEDAnet, deploy a point (e.g. #1, or any other from the range 1..253) on it (perhaps in the same location with the ZeroPoint) and configure it to connect to your node. My site must become available directly once this is done.

From Ilya Wed Sep 10 20:47:01 2025 UTC in reply to this comment

Re: Re: Re: Re: Re: Re: Peer

Thanks, I got it now, it was all confused in my head :-).

From Ilya Thu Sep 11 09:24:26 2025 UTC in reply to this comment

Re: Re: Re: Re: Re: Re: Peer

I checked it today (was too sleepy yesterday), and pinging from my workstation doesnt work - the packets are being forwarded by my server to your site, server then receives the reply, but that reply is never forwarded back to the workstation. The workstation is behind a restricted NAT btw.

From Andrey Stolyarov Thu Sep 11 10:55:41 2025 UTC in reply to this comment

Re: Peer

Restricted NAT (and even symmetric NAT, which is much worse) must be okay for a point, at most it might require setting lesser keepalive_interval in the .fedanet/serv.conf. Try setting it, e.g., to 30. However, to me this doesn't look like the cause for the problem.

I'd check two things now. First, does the IPv6 address on your workstation correspond to the point number you use there: FEDAnet addressing scheme is FEDA:(node-id):PPxx:xxxx, where PP is the point number (in hexadecimal), and xx:xxxx are the point's own address space — so each point has a /104 subnet. Second, is forwarding enabled within the node's serv.conf (there must be a line forwarding yes).

From Ilya Thu Sep 11 11:26:46 2025 UTC in reply to this comment

Re: Re: Peer

Nevermind, I made a spelling mistake when setting up IPv6, it works now

From Yury K. (unverified) Tue Sep 9 22:23:04 2025 UTC

Seems to be working well!

I configured two of my servers and managed to connect them to each other. For some reason, when I tried "type default" in the peer config, it didn't work. So I tried "type natcheck" instead, and now it works — pings, TCP, and UDP.

Here's the config for my primary node:

peer yury
type natcheck
ip 51.15.107.24
port 5430
node_id 5c860ff1872606d5188c
point 42

Public key: http://4kd.xyz/5c860ff1872606d5188c.pub

By the way, I also run a single-page server: http://[feda:5c86:ff1:8726:6d5:188c:2a00:feda]:6080/

From Andrey Stolyarov Wed Sep 10 00:32:02 2025 UTC in reply to this comment

Re: Seems to be working well!

Public key checked and added to the collection. BTW, I've never seen rank 29 before :-) Perhaps I was the first guest to see your site, yes it works.

I'll look into the peer type problem tomorrow, as of now I'm too sleepy.

P.S. I edited your comment to add the <pre> tag for the peer configuration, otherwise it was inconvenient to copy-paste it.

From Yury K. (unverified) Wed Sep 10 07:40:30 2025 UTC in reply to this comment

Re: Re: Seems to be working well!

Sorry, I forgot about pre. Thank you for adding it.

Screenshot of your site (spoiler alert!): http://4kd.xyz/feda-croco.png

From feriman Wed Sep 17 09:57:59 2025 UTC in reply to this comment

Re: Seems to be working well!

Some time ago fedaserv said this: peer 51.15.107.24:5430 says (as plain) we caused error (08, node unknown, introduce yourself)
Now it says: peer 51.15.107.24:5430 says (as plain) we caused error (06, failed to decrypt)

Looks like something went wrong.

From Andrey Stolyarov Wed Sep 17 11:29:41 2025 UTC in reply to this comment