Show HN: connet – A P2P reverse proxy with NAT traversal

[Ingon]

https://github.com/connet-dev/connet

Over the past couple of months, I've been working on connet. At this point, it is working pretty smoothly (in what I use it for), so I wanted to share it with more people and see what they think.

I know many other similar/reverse proxy solutions exist - like https://github.com/fatedier/frp, https://github.com/rapiz1/rathole, and a bunch more you can find at https://github.com/anderspitman/awesome-tunneling. However, I wanted to try and put my own little peer-to-peer twist on it.

Thanks for checking it out, and sharing any feedback you might have!

[r3trohack3r]

This looks great!

Have you seen the libp2p project? Might help get you pluggable NAT traversal and transport strategies plus peer discovery. We’ve been using rust-libp2p for building an overlay network and have had decent success.

[wngr → r3trohack3r]

Also take a look at iroh [0]. It doesn't come with the bloat of ipfs, provides robust core building blocks. They really figured out NAT traversal.

[0]: https://github.com/n0-computer/iroh

[a_bell → wngr]

In my experience both iroh and libp2p fail most of the time and need to revert to relays. The joys of cgnat.

[Arqu → a_bell]

Id urge you to try both out again and verify results. The comment is fairly dismissive, yet both do work even behind a cgnat (albeit not under all conditions). If you do find a general solution to the problem, please do share.

[ycombinatrix → Arqu]

I have the same experience with libp2p. Something is always broken. Last time it was mDNS.

[Ingon → wngr]

Will do, thanks for sharing!

[Ingon → r3trohack3r]

Thanks!

No, I wasn't aware of libp2p. Looks very relevant to what I'm doing, and I'll definitely take a closer look. Thanks for pointing it out!

[Uptrenda → Ingon]

It ain't, trust me. No one who promotes Libp2p ever knows how it works much like users of all of Protocol Labs products. The average "engineer" today rarely looks deeper than the title of the tech they use. They are just glorified plumbers plumbing together pipes filled with [redacted.]

You'll waste your time on Libp2p because it already works almost exactly like your own project. It uses a network of relays as a fallback. It does add in hole punching but no one at Protocol Labs understands how a NAT works. So it only works for a subset of NATs (full cone; restrict; specifically with source port preserving delta behaviours.)

Protocol Labs is filled with big egos and midwits. In 2025, I have zero time for bullshitters and I'm going to call them out for it.

[r3trohack3r → Uptrenda]

I’m not sure what you’re going on about.

The rust-libp2p project has worked really well for me and I’m in the guts of it constantly.

Everything has been pluggable in the right ways so far. Adding new behaviors is straightforward. I can plug and play behaviors, or feature flag them, to pump out purpose built binaries.

It seems like a solid foundation for p2p research and productionizing that research. When I want to experiment with a new protocol, I can plug it in as a behavior without having to solve the rest of the stack.

I have a suspicion that in 2025 imma have to rip open the guts of swarm again to tweak connection management (we are aggressive with connections) but that isn’t daunting.

The only gripe I have with rust-libp2p right now is the learning curve (this was my first rust project - which is probably most of it).

[rudasn]

Nice. I really like the config format regarding the services available/exposed.

Any particular reasons you haven't built upon wireguard that would handle encryption/security for you?

[Ingon → rudasn]

Thanks for taking a look!

Initially, I did think I'll be using wireguard. What stopped me at the time (as far as I remember) was that I couldn't just use the protocol part of the official golang library (e.g. https://git.zx2c4.com/wireguard-go/about/). Another thought I had at the time, was that I would had to use the user-space wireguard implementation, which everyone claimed was slow (I should have probably looked into how slow it is).

Another thought I had was to use the noise protocol (which wiregruard also uses) for security and building on top of that. Which meant I would have to implement most of what QUIC (and wireguard) does to make UDP a reliable protocol - retries, ordering, streams, etc. So, eventually, I just settled on using QUIC for the first version - later we can always add more ways for peers to connect to each other.

[quie → Ingon]

wireguard does not do any retries, ordering or streams, see the whitepaper and the code which are marvels of engineering.

[Ingon → quie]

thanks for correcting me, its been a while since I've looked at the whitepaper

[crtasm]

Suggestion for the quickstart: refer to the clients as either D,S or a,b throughout - I found the mixture a bit confusing.

[Ingon → crtasm]

Thanks for checking it out and pointing this inconsistency! I've updated the readme, hopefully it is less confusing now.

[linuxdude314]

You can do this with SSH alone.

https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4...

[palata → linuxdude314]

But with SSH you won't get NAT traversal and then the direct connection, right? You will forward through a server. Or am I missing something?

[valorzard]

Can I use this to host a Minecraft server? I’ve used hamachi and zero tier in the past, and the former USED to work but stopped recently for some reason

[Ingon → valorzard]

While I haven’t tested it with Minecraft (I was planning to) I believe it should basically work. Let me know how it went if you decide to try it!

[nurettin]

I have been using autossh in production for the past decade without problems. Does frp/ngrok/connet, etc. have any advantage that I don't know about?

[Ingon → nurettin]

At first I was confused as how autossh was relevant here, since it seemed like a supervisor for the ssh process (from https://github.com/Autossh/autossh). Then I realized that you are probably running ssh (reverse) tunnels. If that works for you, I don't think you should change!

With others, I think its a mixed bag, in no particular order:

* in my experience, opening up new connections in SSH is somewhat slow (compared to QUIC and ngrok). I believe this was due to how SSH verifies each new stream.

* connet (and others that use UDP based protocols) don't experience the TCP head of line blocking issue. This might not be an issue necessarily, especially if you have a good, consistent connection between peers.

* some of the other tools provide much richer interface (compared to raw SSH), like traffic inspection and modification, different security properties, etc

* connet (and others) does allow multiple destinations and sources binding on the same name, so you can have multiple clients talking to a clustered service

This is it off the top of my mind. Thanks for checking connet out!

[hailruda]

So if I understand correctly, this should be comparable to what Tailscale is doing?

[Ingon → hailruda]

You can achieve a similar effect with both, yes. However, they fundamentally work differently.

Tailscale (e.g. wireguard) is a way to create a virtual private network between two (or more) machines. This means they can pretend they are on the same network, even if they are physically on different networks. Now, having them on the same (virtual) network, means you can open up the firewall on the target machine (for that specific network), and access services that are running there. You'll still need to use the other machine's IP address/name on that network to access it.

connet on the other hand is more like a projection (or tunnel) - it opens up a TCP listener on your local machine, and internally forwards all connections and traffic to the TCP listener that is running on the remote machine. At your local machine, it looks like you are running the target service locally, and you access it via localhost.

I hope this explains how is connet different from Tailscale, thanks for checking it out!

[Uptrenda]

Spent 2 years working on the same problem. Ended up designing a library that does:

- direct connect

- reverse connect

- tcp hole punching

- turn support

Has other features too like:

- multi-interface

- duel-stack

- port forwarding and pin holes

Show some love cause its at 64 stars and is IMO, objectively better for direct peer-to-peer networking than OPs library that only supports direct, reverse, and relay, and which doesn't seem to do anything to open ports or firewalls. It does make me salty that I try so hard with my own work but what seems to make people successful is their ability to get lucky on sites like this or game them.

No offense to OP. Here's my project: https://github.com/robertsdotpm/p2pd

[yownie → Uptrenda]

≥- duel-stack

dual-stack

unless they have sabers

[Uptrenda → yownie]

Maybe they do, TCP hole punching is like a duel in a way. You are right tho, my spelling is horrible. Hope my message above doesn't come off in bad taste. I should be happy for the OP I guess.

[Ingon → Uptrenda]

connet is a young project, and draws inspiration from many great projects like yours. Thanks for sharing it, I starred it!

[Uptrenda → Ingon]

thanks man, sorry if i came off harshly will edit my post tbh, its a bad look. keep working on your project. I do see the need for what you're doing.

[SupremeQuartz → Uptrenda]

"Love me overwatch. Love cheese pizza. Love Indian food. Love nature. Love the rain. Love me aul ma. Love me grand parents. Love ...love...love..."

there ain't no god damn way, bro